Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lULK4-0006ft-1C for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Apr 2021 03:27:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lULK2-0006KF-Pc for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Apr 2021 03:27:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lULK2-0006HS-JA for pgsql-hackers@lists.postgresql.org; Thu, 08 Apr 2021 03:27:10 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lULK0-0000Hv-Mq for pgsql-hackers@lists.postgresql.org; Thu, 08 Apr 2021 03:27:09 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 7BE985805D7; Wed, 7 Apr 2021 23:27:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 07 Apr 2021 23:27:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=M2itLNgrrCND+md+6XQoYrK4pT3g8kiAzJRF0CslL8E=; b=feZr/2Ll d+LtqH5+Uc9qDoSlcIfuQcpGW8/VnxpiyXY+2ZwVh5SghJUAId1sNpKg4qCidboC PuWxeRPmSwlZcX4dSlsYtxh6wESkJlk/S7+zaQV3kaPfFcOJxQGEIomUCD6nOtNy tQqW+MK0QeDYQqresFKPiVA2V5ITckWx4S5OBk+WLvDzc9jxfX1UdDVmInF17u+A j4sWi844+8V2v2sP9EBFcysv2uze9DNhhi7dIaSTNqLTO85l6QV4Q6v9pFYg+UpL iQyI2q1y1sBO2iDVqio7fvLDSDMbrnq5fTbt/if/KaA0OndR1/+acD4y1AjDWWG6 fJ0V9MnDwbTIGg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudejkedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesthekredttderudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepueffhfejieeuueffgedvudekgeeltdeviedvieeufeei ieevgfetheeufeethedvnecukfhppeduledtrdelhedrudelrdelheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA id C7D67240057; Wed, 7 Apr 2021 23:27:05 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 33C742A0BC0; Wed, 7 Apr 2021 23:27:04 -0400 (-04) Date: Wed, 7 Apr 2021 23:27:04 -0400 From: Alvaro Herrera To: Bruce Momjian Cc: Julien Rouhaud , Tom Lane , Nitin Jadhav , Hannu Krosing , Robert Haas , Pavel Stehule , Michael Paquier , torikoshia , Atsushi Torikoshi , Tatsuro Yamada , Tomas Vondra , Evgeny Efimkin , PostgreSQL Hackers Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? Message-ID: <20210408032704.GA7498@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210408024229.GJ24239@momjian.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Apr-07, Bruce Momjian wrote: > On Thu, Apr 8, 2021 at 10:38:08AM +0800, Julien Rouhaud wrote: > > Thanks! And I agree with using query_id in the new field names while keeping > > queryid for pg_stat_statements to avoid unnecessary query breakage. > > I think we need more feedback from the group. Do people agree with the > idea above? The question is what to call: > > GUC compute_queryid > pg_stat_activity.queryid > pg_stat_statements.queryid > > using "queryid" or "query_id", and do they have to match? Seems a matter of personal preference. Mine is to have the underscore everywhere in backend code (where this is new), and let it without the underscore in pg_stat_statements to avoid breaking existing code. Seems to match what Julien is saying. -- Álvaro Herrera Valdivia, Chile "La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)