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 or bytea_output. 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(). Now, that would create a debate about backwards compatibility and whether making bool output more readable was worth possibly breaking some applications, but I do not think this patch should escape scrutiny for the same issue. There are plenty of people with shell scripts that look at psql output, which might get broken by careless use of this \pset. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers