Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZwxjI-0006Nf-70 for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Nov 2015 19:40:20 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZwxjH-0005zV-5J for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Nov 2015 19:40:19 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1Zwxhw-0004RH-FQ for pgsql-hackers@postgresql.org; Thu, 12 Nov 2015 19:38:56 +0000 Received: from verite.pro ([195.154.189.246] helo=genius-map.net) by makus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1Zwxhs-000106-Tn for pgsql-hackers@postgresql.org; Thu, 12 Nov 2015 19:38:55 +0000 Received: by genius-map.net (Postfix, from userid 1001) id 1326538A150E; Thu, 12 Nov 2015 20:38:51 +0100 (CET) Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: psql: add \pset true/false From: "Daniel Verite" To: "Matthijs van der Vleuten" CC: "Brendan Jurd" , "Tom Lane" , "Marko Tiikkaja" , "PostgreSQL hackers" In-Reply-To: Date: Thu, 12 Nov 2015 20:38:49 +0100 Message-ID: <779ab8a4-2364-4980-bd2f-49e83619d701@mm> X-Mailer: Manitou v1.4.0 X-Pg-Spam-Score: -1.9 (-) 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 Matthijs van der Vleuten wrote: > -1 for changing boolout(). It will break anything that receives=20 > boolean values from the server. Not if the default output is still 't' or 'f' like now. Nobody seems to suggest a gratuitous compatibility break. > How a client is going to display values (of any > type) is logic that should belong in the client, not in the protocol. Maybe in general, but consider two problems here: #1: postgres type extensibility implies that clients display values from types they know nothing about. It makes sense that they just use the text representation that comes from the server, unless they have a specific reason not to. #2: in the case of built-in types, like boolean, it's not sufficient to change how the base type gets displayed. With Marko's patch, array[true,false] is still displayed as {t,f} when setting aternatives through the proposed \pset feature. Same problem inside composite types as mentioned upthread. The issue with the patch's approach is that it falls short of identifying bools in all situations, so the results are inconsistent. Solving that in psql is hard or possibly irrealistic, because the reliance on the text representation for complex types goes deep. By contrast, making the server-side representation configurable seems easier. Plus it might be of interest for other consumers of resultsets, outside of psql. Best regards, --=20 Daniel V=E9rit=E9 PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite --=20 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers