Re: [HACKERS] psql: add \pset true/false

2015-12-09 Thread Michael Paquier
On Wed, Dec 9, 2015 at 8:50 PM, Michael Paquier wrote: > On Tue, Dec 8, 2015 at 8:51 PM, Michael Paquier > wrote: >> On Tue, Dec 8, 2015 at 7:18 PM, Kyotaro HORIGUCHI >> wrote: >>> At Sat, 5 Dec 2015 21:05:29 +0900, Michael Paquier >>> wrote in >>> >>> > Regarding the patch, I >>> > would te

Re: [HACKERS] psql: add \pset true/false

2015-12-09 Thread Michael Paquier
On Tue, Dec 8, 2015 at 8:51 PM, Michael Paquier wrote: > On Tue, Dec 8, 2015 at 7:18 PM, Kyotaro HORIGUCHI > wrote: >> At Sat, 5 Dec 2015 21:05:29 +0900, Michael Paquier >> wrote in >> >> > Regarding the patch, I >> > would tend to think that we should just reject it and try to cruft >> > som

Re: [HACKERS] psql: add \pset true/false

2015-12-08 Thread Michael Paquier
On Tue, Dec 8, 2015 at 7:18 PM, Kyotaro HORIGUCHI wrote: > At Sat, 5 Dec 2015 21:05:29 +0900, Michael Paquier > wrote in > > > Regarding the patch, I > > would tend to think that we should just reject it and try to cruft > > something that could be more pluggable if there is really a need. > >

Re: [HACKERS] psql: add \pset true/false

2015-12-08 Thread Kyotaro HORIGUCHI
Hello, At Sat, 5 Dec 2015 21:05:29 +0900, Michael Paquier wrote in > On Fri, Dec 4, 2015 at 6:06 PM, Pavel Stehule wrote: > > long time I am dream about integrating Lua to psql > > > > It is fast enough for these purpose and can be used for custom macros, .. > > Things are perhaps digressing

Re: [HACKERS] psql: add \pset true/false

2015-12-05 Thread Michael Paquier
On Fri, Dec 4, 2015 at 6:06 PM, Pavel Stehule wrote: > long time I am dream about integrating Lua to psql > > It is fast enough for these purpose and can be used for custom macros, .. Things are perhaps digressing too much here... Regarding the patch, I would tend to think that we should just rej

Re: [HACKERS] psql: add \pset true/false

2015-12-04 Thread Pavel Stehule
2015-12-04 9:37 GMT+01:00 Kyotaro HORIGUCHI : > Hello, I think this is the my last proposal of an idea on > psql-side generic solution. Sorry for bothering. > > > My environment is CentOS7. But completely forgot Windows > > environment (or other platforms). I agree with you. It will > > indeed too

Re: [HACKERS] psql: add \pset true/false

2015-12-04 Thread Kyotaro HORIGUCHI
Hello, I think this is the my last proposal of an idea on psql-side generic solution. Sorry for bothering. > My environment is CentOS7. But completely forgot Windows > environment (or other platforms). I agree with you. It will > indeed too much considering all possible platforms. Ok, DLL is not

Re: [HACKERS] psql: add \pset true/false

2015-12-03 Thread Daniel Verite
Jim Nasby wrote: > I was more thinking it would be nice to be able to temporarily > over-ride/wrap what an output function is doing. AFAIK that would allow > this to work everywhere (row(), copy, etc). I don't know of any remotely > practical way to do that, though. Yes. Something like

Re: [HACKERS] psql: add \pset true/false

2015-12-02 Thread Kyotaro HORIGUCHI
Hello, it's disappointing. At Thu, 3 Dec 2015 15:48:50 +0900, Michael Paquier wrote in > On Thu, Dec 3, 2015 at 2:53 PM, Kyotaro HORIGUCHI > wrote: > > The attached patch adds a function to load output filter DLL. > > The second file is an example filter module. The following > > commandline w

Re: [HACKERS] psql: add \pset true/false

2015-12-02 Thread Michael Paquier
On Thu, Dec 3, 2015 at 2:53 PM, Kyotaro HORIGUCHI wrote: > The attached patch adds a function to load output filter DLL. > The second file is an example filter module. The following > commandline with the file can create a test filter module. I > suppose preload feature only needs additional few l

Re: [HACKERS] psql: add \pset true/false

2015-12-02 Thread Kyotaro HORIGUCHI
Hello, the attched is an example implement of output filter dynamic loading feature of psql. At Thu, 3 Dec 2015 10:41:11 +0900, Michael Paquier wrote in > > How about plugins on psql side? Calling hooked function in > > printQuery could do that on psql. Impact on psql itself is > > minimized. (

Re: [HACKERS] psql: add \pset true/false

2015-12-02 Thread Michael Paquier
On Thu, Dec 3, 2015 at 10:09 AM, Kyotaro HORIGUCHI wrote: > Hello, > > At Thu, 3 Dec 2015 09:24:35 +0900, Michael Paquier > wrote in > >> On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote: >> > On 11/15/15 7:37 PM, Peter Eisentraut wrote: >> > I was more thinking it would be nice to be able to

Re: [HACKERS] psql: add \pset true/false

2015-12-02 Thread Kyotaro HORIGUCHI
Hello, At Thu, 3 Dec 2015 09:24:35 +0900, Michael Paquier wrote in > On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote: > > On 11/15/15 7:37 PM, Peter Eisentraut wrote: > > I was more thinking it would be nice to be able to temporarily > > over-ride/wrap what an output function is doing. AFAIK t

Re: [HACKERS] psql: add \pset true/false

2015-12-02 Thread Michael Paquier
On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote: > On 11/15/15 7:37 PM, Peter Eisentraut wrote: >> >> On 11/15/15 3:20 PM, Jim Nasby wrote: >>> >>> As to the argument about displaying a check or an X, why should that >>> capability only exist for boolean types? For example, why not allow psql >>>

Re: [HACKERS] psql: add \pset true/false

2015-12-02 Thread Jim Nasby
On 11/15/15 7:37 PM, Peter Eisentraut wrote: On 11/15/15 3:20 PM, Jim Nasby wrote: As to the argument about displaying a check or an X, why should that capability only exist for boolean types? For example, why not allow psql to convert a numeric value into a bar of varying sizes? I've frequently

Re: [HACKERS] psql: add \pset true/false

2015-12-02 Thread Daniel Verite
Michael Paquier wrote: > So, looking at this thread, here is the current status: > - Tom Lane: -1 > - Michael Paquier: -1 > - Peter Geoghegan: +1? > - Peter Eisentraut: +1 > - the author: surely +1. > Any other opinions? Feel free to correct this list if needed, and then > let's try to mov

Re: [HACKERS] psql: add \pset true/false

2015-12-01 Thread Michael Paquier
On Mon, Nov 16, 2015 at 10:43 AM, Peter Geoghegan wrote: > On Thu, Nov 12, 2015 at 1:09 PM, Tom Lane wrote: >> Peter Eisentraut writes: >>> Plus we already have \pset numericlocale as a similar feature in psql. >> >> But \pset numericlocale is also a crock. It doesn't affect COPY output >> for

Re: [HACKERS] psql: add \pset true/false

2015-11-15 Thread Peter Geoghegan
On Thu, Nov 12, 2015 at 1:09 PM, Tom Lane wrote: > Peter Eisentraut writes: >> Plus we already have \pset numericlocale as a similar feature in psql. > > But \pset numericlocale is also a crock. It doesn't affect COPY output > for instance, and its ability to identify which data types it should

Re: [HACKERS] psql: add \pset true/false

2015-11-15 Thread Peter Eisentraut
On 11/15/15 3:20 PM, Jim Nasby wrote: > As to the argument about displaying a check or an X, why should that > capability only exist for boolean types? For example, why not allow psql > to convert a numeric value into a bar of varying sizes? I've frequently > emulated that with something like SELEC

Re: [HACKERS] psql: add \pset true/false

2015-11-15 Thread Peter Eisentraut
On 11/12/15 4:09 PM, Tom Lane wrote: > Peter Eisentraut writes: >> Plus we already have \pset numericlocale as a similar feature in psql. > > But \pset numericlocale is also a crock. It doesn't affect COPY output > for instance, and its ability to identify which data types it should apply > to i

Re: [HACKERS] psql: add \pset true/false

2015-11-15 Thread Jim Nasby
On 11/12/15 3:09 PM, Tom Lane wrote: Peter Eisentraut writes: Plus we already have \pset numericlocale as a similar feature in psql. But \pset numericlocale is also a crock. It doesn't affect COPY output for instance, and its ability to identify which data types it should apply to is really

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Tom Lane
Peter Eisentraut writes: > Plus we already have \pset numericlocale as a similar feature in psql. But \pset numericlocale is also a crock. It doesn't affect COPY output for instance, and its ability to identify which data types it should apply to is really shaky. And it's virtually unused, as d

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Peter Eisentraut
On 10/29/15 9:50 AM, Tom Lane wrote: > The really key argument that hasn't been addressed here is why does such > a behavior belong in psql, rather than elsewhere? Because it is the job of the client to mangle the data so that it suits the purposes of the client. What comes over the wire is part

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread David G. Johnston
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 wrote: > >> Marko Tiikkaja writes: >> > On 10/29/15 11:51 AM, Daniel Verite wrote: >> >> Personally I think it would be worth having, but how about >> >> booleans i

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread David G. Johnston
On Thu, Oct 29, 2015 at 6:50 AM, Tom Lane wrote: > Marko Tiikkaja 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 th

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread David G. Johnston
On Thu, Oct 29, 2015 at 5:28 AM, Matthijs van der Vleuten wrote: > I have had exactly this situation a week ago. I was testing the output of > an algorithm that is supposed to have exactly one true value per input id. > ​If this is particularly important I would add something like (and(col1, col

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Daniel Verite
Matthijs van der Vleuten wrote: > -1 for changing boolout(). It will break anything that receives > 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 value

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Pavel Stehule
2015-11-12 17:41 GMT+01:00 Matthijs van der Vleuten : > > On 12 Nov 2015, at 14:21, Brendan Jurd wrote: > > On Fri, 30 Oct 2015 at 00:51 Tom Lane wrote: > >> The really key argument that hasn't been addressed here is why does such >> a behavior belong in psql, rather than elsewhere? Surely legi

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Vik Fearing
On 11/12/2015 05:41 PM, Matthijs van der Vleuten wrote: > >> On 12 Nov 2015, at 14:21, Brendan Jurd wrote: >> >> On Fri, 30 Oct 2015 at 00:51 Tom Lane > > wrote: >> The really key argument that hasn't been addressed here is why does such >> a behavior belong in psql, ra

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Matthijs van der Vleuten
> On 12 Nov 2015, at 14:21, Brendan Jurd wrote: > > On Fri, 30 Oct 2015 at 00:51 Tom Lane > wrote: > 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 uniqu

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Vik Fearing
On 10/28/2015 10:03 AM, Marko Tiikkaja wrote: > Hello hello, > > Since the default t/f output for booleans is not very user friendly, > attached is a patch which enables you to do for example the following: > > =# \pset true TRUE > Boolean TRUE display is "TRUE". > =# \pset false FALSE > Boolean

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Brendan Jurd
On Fri, 30 Oct 2015 at 00:51 Tom Lane wrote: > 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 datat

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Marko Tiikkaja
On 11/12/15 1:50 PM, Michael Paquier wrote: FWIW, I am -1 on the concept of enforcing output values for particular datatypes because that's not the job of psql In my view, the job of psql is to make working with a postgres database easy for us human beings. That means (among other things) for

Re: [HACKERS] psql: add \pset true/false

2015-11-12 Thread Michael Paquier
On Thu, Oct 29, 2015 at 10:50 PM, Tom Lane wrote: > Marko Tiikkaja 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 cl

Re: [HACKERS] psql: add \pset true/false

2015-10-29 Thread Tom Lane
Marko Tiikkaja 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

Re: [HACKERS] psql: add \pset true/false

2015-10-29 Thread Marko Tiikkaja
On 10/29/15 11:51 AM, Daniel Verite wrote: Marko Tiikkaja wrote: Since the default t/f output for booleans is not very user friendly, attached is a patch which enables you to do for example the following: Personally I think it would be worth having, but how about booleans inside ROW()

Re: [HACKERS] psql: add \pset true/false

2015-10-29 Thread Daniel Verite
Marko Tiikkaja wrote: > Since the default t/f output for booleans is not very user friendly, > attached is a patch which enables you to do for example the following: Personally I think it would be worth having, but how about booleans inside ROW() or composite types ? test=> \pset true 1

Re: [HACKERS] psql: add \pset true/false

2015-10-29 Thread Robert Haas
On Thu, Oct 29, 2015 at 1:32 AM, Marko Tiikkaja wrote: >> 2. If you're the sort of person liable to be confused by t/f, you >> probably aren't in the target audience for psql anyway. > > Really? The difference between t/f is that the vertical squiggle is > flipped, THAT'S IT. Consider: > > t t f

Re: [HACKERS] psql: add \pset true/false

2015-10-28 Thread Marko Tiikkaja
On 10/28/15 11:52 PM, Robert Haas wrote: -0 on this concept from me. I'm not going to vigorously oppose it, but: 1. You can always do it in the query if you really want it. True, but not always practical. 2. If you're the sort of person liable to be confused by t/f, you probably aren't in t

Re: [HACKERS] psql: add \pset true/false

2015-10-28 Thread Andres Freund
On 2015-10-28 23:38:45 +, Greg Stark wrote: > On Wed, Oct 28, 2015 at 10:52 PM, Robert Haas wrote: > > 3. I really don't want to end up with a bunch of features of this type > > for a variety of different data types. > > We already have \pset null which feels very similar. It's data type neu

Re: [HACKERS] psql: add \pset true/false

2015-10-28 Thread Greg Stark
On Wed, Oct 28, 2015 at 10:52 PM, Robert Haas wrote: > 3. I really don't want to end up with a bunch of features of this type > for a variety of different data types. We already have \pset null which feels very similar. It's not like 'f' and 't' are terribly common and probably different from how

Re: [HACKERS] psql: add \pset true/false

2015-10-28 Thread Robert Haas
On Wed, Oct 28, 2015 at 10:03 AM, Marko Tiikkaja wrote: > Hello hello, > > Since the default t/f output for booleans is not very user friendly, > attached is a patch which enables you to do for example the following: > > =# \pset true TRUE > Boolean TRUE display is "TRUE". > =# \pset false FALSE >

[HACKERS] psql: add \pset true/false

2015-10-28 Thread Marko Tiikkaja
Hello hello, Since the default t/f output for booleans is not very user friendly, attached is a patch which enables you to do for example the following: =# \pset true TRUE Boolean TRUE display is "TRUE". =# \pset false FALSE Boolean FALSE display is "FALSE". =# select true, false; bool | boo