On Thu, Oct 29, 2015 at 6:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Marko Tiikkaja <marko@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.
