On Thu, Nov 12, 2015 at 1:04 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:

> On Thu, Oct 29, 2015 at 6:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Marko Tiikkaja <ma...@joh.to> writes:
>> > On 10/29/15 11:51 AM, Daniel Verite wrote:
>> >> Personally I think it would be worth having, but how about
>> >> booleans inside ROW() or composite types ?
>> > There's not enough information sent over to do that in the client.
>> > Note that this works the same way as  \pset null  with  SELECT
>> > ROW(NULL), so I don't consider it a show stopper for the patch.
>> The problem with that argument is that \pset null is already a kluge
>> (but at least a datatype-independent one).  Now you've added a datatype
>> specific kluge of the same ilk.  It might be useful, it might be short,
>> but that doesn't make it not a kluge.
>> The really key argument that hasn't been addressed here is why does such
>> a behavior belong in psql, rather than elsewhere?  Surely legibility
>> problems aren't unique to psql users.  Moreover, there are exactly
>> parallel facilities for other datatypes on the server side: think
>> DateStyle
> ​Which provides a finite set of possible values.
> ​
>> or bytea_output.
> ​Wasn't this added mostly for performance as opposed to dealing with
> "locale/style" considerations?​
> So if you were trying to follow precedent
>> rather than invent a kluge, you'd have submitted a patch to create a GUC
>> that changes the output of boolout().
> ​I'm leaning toward doing this in the client if its offered at all.  An
> unobtrusive usability enhancement - even if limited to non-embedded
> situations - that seems like little effort for a measurable gain.
​That said whatever is done really wants to be able to interact with at
least "psql \copy" but probably "SQL COPY" as well...again even if just
non-composite outputs.

David J.​

Reply via email to