Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cUZlk-0006Uc-2f for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Jan 2017 14:02:20 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cUZli-0007ey-V9 for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Jan 2017 14:02:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cUZli-0007es-Cn for pgsql-hackers@postgresql.org; Fri, 20 Jan 2017 14:02:18 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cUZlf-0000l9-0M for pgsql-hackers@postgresql.org; Fri, 20 Jan 2017 14:02:17 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v0KE2ATe025607; Fri, 20 Jan 2017 09:02:10 -0500 From: Tom Lane To: "Daniel Verite" cc: "Ashutosh Sharma" , "Rahila Syed" , "Stephen Frost" , "Ashutosh Bapat" , "pgsql-hackers" Subject: Re: Improvements in psql hooks for variables In-reply-to: <1dee8049-2bb7-428c-bef4-46745722c61e@manitou-mail.org> References: <1dee8049-2bb7-428c-bef4-46745722c61e@manitou-mail.org> Comments: In-reply-to "Daniel Verite" message dated "Fri, 20 Jan 2017 14:44:12 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25605.1484920929.1@sss.pgh.pa.us> Date: Fri, 20 Jan 2017 09:02:10 -0500 Message-ID: <25606.1484920930@sss.pgh.pa.us> X-Pg-Spam-Score: -5.1 (-----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org "Daniel Verite" writes: > Setting ENCODING has no effect, like DBNAME, USER, HOST and PORT. > In a way, it's a read-only variable that's here to inform the user, > not as a means to change the encoding (\encoding does that and > has proper support for tab completion) Right. > What we could do as of this patch is emit an error when we try > to change ENCODING, with a hook returning false and > a proper error message hinting to \encoding. I think that the current behavior is intentional: it avoids making those variables reserved. That is, if you're unaware that psql sets them and try to use them for your own purposes, it will work. However, it only really works if psql never overwrites the values after startup, whereas I believe all of these are overwritten by a \c command. So maybe it's more user-friendly to make these variables fully reserved, even at the risk of breaking existing scripts. But I don't think it's exactly an open-and-shut question. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers