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.
