Re: [HACKERS] psql completion for ids in multibyte string

On Fri, Mar 4, 2016 at 12:02 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI >> wrote: >> > Hello, thank you for the comments. >> >> I think we should leave string_length as it is and

Re: [HACKERS] psql completion for ids in multibyte string

On Wed, Mar 2, 2016 at 8:07 PM, Kyotaro HORIGUCHI wrote: > Hello, thank you for the comments. >> I think we should leave string_length as it is and use a new variable >> for character-based length, as in the attached. > > Basically agreed but I like byte_length

Re: [HACKERS] psql completion for ids in multibyte string

On Thu, Mar 3, 2016 at 2:07 PM, Kyotaro HORIGUCHI wrote: > Hello, thank you for the comments. > > At Wed, 2 Mar 2016 10:10:55 +1300, Thomas Munro > wrote in >

Re: [HACKERS] psql completion for ids in multibyte string

Hello, thank you for the comments. At Wed, 2 Mar 2016 10:10:55 +1300, Thomas Munro wrote in

Re: [HACKERS] psql completion for ids in multibyte string

On Wed, Mar 2, 2016 at 7:54 AM, Robert Haas wrote: > On Mon, Feb 29, 2016 at 6:32 PM, Thomas Munro > wrote: >> On Fri, Feb 26, 2016 at 6:34 PM, Kyotaro HORIGUCHI >> wrote: >>> Hello, this is the second patch

Re: [HACKERS] psql completion for ids in multibyte string

On Mon, Feb 29, 2016 at 6:32 PM, Thomas Munro wrote: > On Fri, Feb 26, 2016 at 6:34 PM, Kyotaro HORIGUCHI > wrote: >> Hello, this is the second patch plitted out. This allows >> multibyte names to be completed in psql. >> >> At Fri,

Re: [HACKERS] psql completion for ids in multibyte string

On Fri, Feb 26, 2016 at 6:34 PM, Kyotaro HORIGUCHI wrote: > Hello, this is the second patch plitted out. This allows > multibyte names to be completed in psql. > > At Fri, 06 Nov 2015 11:47:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI >

Re: [HACKERS] psql completion for ids in multibyte string

Hello, this is the second patch plitted out. This allows multibyte names to be completed in psql. At Fri, 06 Nov 2015 11:47:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20151106.114717.170526268.horiguchi.kyot...@lab.ntt.co.jp> > At Thu, 5 Nov

Re: format() changes discussion (was: Re: [HACKERS] psql metaqueries with \gexec)

On 2/22/16 5:16 PM, Corey Huinker wrote: (One thing I had to come up with was processing of arrays, which you also see in that example JSON -- it's the specifiers that have a colon inside the {}. The part after the colon is used as separator between the array elements, and each

Re: [HACKERS] psql metaqueries with \gexec

On 2/22/16 5:13 PM, Alvaro Herrera wrote: Jim Nasby wrote: On 2/22/16 11:47 AM, Alvaro Herrera wrote: Pavel Stehule wrote: The design of the "format" function is not closed. Try to send prototype and patch. The possibility to do PostgreSQL customization was strong reason why we didn't

format() changes discussion (was: Re: [HACKERS] psql metaqueries with \gexec)

> > (One thing I had to come up with was processing of arrays, which you > also see in that example JSON -- it's the specifiers that have a colon > inside the {}. The part after the colon is used as separator between > the array elements, and each element is expanded separately.) > > I'm

Re: [HACKERS] psql metaqueries with \gexec

Jim Nasby wrote: > On 2/22/16 11:47 AM, Alvaro Herrera wrote: > >Pavel Stehule wrote: > > > >>The design of the "format" function is not closed. Try to send prototype > >>and patch. The possibility to do PostgreSQL customization was strong reason > >>why we didn't implemented "sprintf" and we

Re: [HACKERS] psql metaqueries with \gexec

On 2/22/16 11:47 AM, Alvaro Herrera wrote: Pavel Stehule wrote: The design of the "format" function is not closed. Try to send prototype and patch. The possibility to do PostgreSQL customization was strong reason why we didn't implemented "sprintf" and we implemented "format". Probably not

Re: [HACKERS] psql metaqueries with \gexec

> > In the mean time, update patch attached. > > Really attached this time. diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 9750a5b..5ca769f 100644 --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -849,6 +849,13 @@ exec_command(const char *cmd, status

Re: [HACKERS] psql metaqueries with \gexec

On Mon, Feb 22, 2016 at 11:30 AM, Corey Huinker wrote: > On Mon, Feb 22, 2016 at 10:08 AM, Daniel Verite > wrote: > >> Corey Huinker wrote: >> >> > ...and query text visibility, and result visibility, and error handling, >> > etc. In

Re: [HACKERS] psql metaqueries with \gexec

Pavel Stehule wrote: > The design of the "format" function is not closed. Try to send prototype > and patch. The possibility to do PostgreSQL customization was strong reason > why we didn't implemented "sprintf" and we implemented "format". Probably not terribly useful here, but for the

Re: [HACKERS] psql metaqueries with \gexec

On Mon, Feb 22, 2016 at 10:08 AM, Daniel Verite wrote: > Corey Huinker wrote: > > > ...and query text visibility, and result visibility, and error handling, > > etc. In this case, we're leveraging the psql environment we'd already set > > up, and if there's an

Re: [HACKERS] psql metaqueries with \gexec

Corey Huinker wrote: > ...and query text visibility, and result visibility, and error handling, > etc. In this case, we're leveraging the psql environment we'd already set > up, and if there's an error, \set ECHO queries shows us the errant SQL as > if we typed it ourselves.. BTW, about

Re: [HACKERS] psql metaqueries with \gexec

> > FWIW, I also wish we had something better than format() for this stuff. I > did create [1] towards that end, but it currently depends on some C code, > which is cumbersome. For the most party, I'm pretty thrilled with format(), though: - I'll admit to being grumpy about the %1$s notation,

Re: [HACKERS] psql metaqueries with \gexec

> > I like what you've proposed, though I am wondering if you considered doing > something server-side instead? It seems a shame to do all this work and > exclude all other tools. > I have, but my solutions closely mirror the one you mention in the next paragraph. > I frequently find myself

Re: [HACKERS] psql metaqueries with \gexec

On 2/19/16 7:32 PM, Corey Huinker wrote: Wow, and I thought *I* liked metaprogramming! :) I like what you've proposed, though I am wondering if you considered doing something server-side instead? It seems a shame to do all this work and exclude all other tools. I frequently find myself

Re: [HACKERS] psql - -dry-run option

On 12/18/15 2:50 AM, Shulgin, Oleksandr wrote: On Thu, Dec 17, 2015 at 9:13 PM, Tom Lane > wrote: Whether we really need a feature like that isn't clear though; it's not like it's hard to test things that way now. Stick in a BEGIN with no

Re: [HACKERS] psql - -dry-run option

On 18 December 2015 at 16:50, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > I'm on the same line: BEGIN/ROLLBACK requires trivial effort and a > --dry-run option might give a false sense of security, but it cannot > possibly rollback side-effects of user functions which modify

Re: [HACKERS] psql - -dry-run option

On Thu, Dec 17, 2015 at 9:13 PM, Tom Lane wrote: > > Whether we really need a feature like that isn't clear though; it's not > like it's hard to test things that way now. Stick in a BEGIN with no > COMMIT, you're there. The problem only comes in if you start expecting > the

Re: [HACKERS] psql - -dry-run option

2015-12-17 20:14 GMT+01:00 Pavel Stehule : > > > 2015-12-17 20:03 GMT+01:00 Tom Lane : > >> Pavel Stehule writes: >> > when I read a blog >> > >>

Re: [HACKERS] psql - -dry-run option

Joe Conway wrote: > On 12/17/2015 11:58 AM, Christopher Browne wrote: > > On 17 December 2015 at 14:16, Pavel Stehule > > wrote: > >> or different idea - just enforce syntax check without execution. > > > > That seems pretty cool... I'd

Re: [HACKERS] psql - -dry-run option

2015-12-17 20:03 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > when I read a blog > > > http://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ > > where is emulated dry-run mode, I though so we

Re: [HACKERS] psql - -dry-run option

On 12/17/2015 11:58 AM, Christopher Browne wrote: > On 17 December 2015 at 14:16, Pavel Stehule > wrote: >> or different idea - just enforce syntax check without execution. > > That seems pretty cool... I'd find "syntax check without

Re: [HACKERS] psql - -dry-run option

Pavel Stehule writes: > when I read a blog > http://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ > where is emulated dry-run mode, I though so we can implement it very > simply. Not one that is actually reliable.

Re: [HACKERS] psql - -dry-run option

On 17 December 2015 at 14:16, Pavel Stehule wrote: > or different idea - just enforce syntax check without execution. That seems pretty cool... I'd find "syntax check without execution" to be pretty useful to test SQL (and especially DDL). -- When confronted by a

Re: [HACKERS] psql - -dry-run option

Christopher Browne writes: > On 17 December 2015 at 14:16, Pavel Stehule wrote: >> or different idea - just enforce syntax check without execution. > That seems pretty cool... I'd find "syntax check without execution" to be > pretty useful to test

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On 2015-12-14 12:18:27 +0100, Andres Freund wrote: > On 2015-12-12 21:04:31 +0900, Michael Paquier wrote: > > Hi all, > > > > I just bumped into the following thing while looking again at Thomas' > > patch for psql tab completion: > > --- a/src/bin/psql/tab-complete.c > > +++

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On Mon, Dec 14, 2015 at 8:18 PM, Andres Freund wrote: > On 2015-12-12 21:04:31 +0900, Michael Paquier wrote: >> Hi all, >> >> I just bumped into the following thing while looking again at Thomas' >> patch for psql tab completion: >> --- a/src/bin/psql/tab-complete.c >> +++

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On 2015-12-14 20:58:21 +0900, Michael Paquier wrote: > On Mon, Dec 14, 2015 at 8:49 PM, Andres Freund wrote: > > On 2015-12-14 20:44:20 +0900, Michael Paquier wrote: > >> + /* > >> + * ALTER TABLE,INDEX,MATERIALIZED VIEW ALL IN TABLESPACE xxx OWNED > >> BY xxx > >> +

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On Mon, Dec 14, 2015 at 9:08 PM, Andres Freund wrote: > ALTER TABLE ALL IN TABLESPACE pg_default OWNED BY andres SET TABLESPACE > works, because of Missed that. - /* If we have TABLE SET TABLESPACE provide a list of tablespaces */ - else if

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On Mon, Dec 14, 2015 at 8:49 PM, Andres Freund wrote: > On 2015-12-14 20:44:20 +0900, Michael Paquier wrote: >> + /* >> + * ALTER TABLE,INDEX,MATERIALIZED VIEW ALL IN TABLESPACE xxx OWNED BY >> xxx >> + * SET TABLESPACE. >> + */ >> + else if

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On Mon, Dec 14, 2015 at 8:36 PM, Andres Freund wrote: > On 2015-12-14 12:18:27 +0100, Andres Freund wrote: >> On 2015-12-12 21:04:31 +0900, Michael Paquier wrote: >> > Hi all, >> > >> > I just bumped into the following thing while looking again at Thomas' >> > patch for psql

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On 2015-12-12 21:04:31 +0900, Michael Paquier wrote: > Hi all, > > I just bumped into the following thing while looking again at Thomas' > patch for psql tab completion: > --- a/src/bin/psql/tab-complete.c > +++ b/src/bin/psql/tab-complete.c > @@ -1040,7 +1040,7 @@ psql_completion(const char

Re: [HACKERS] psql tab completion bug for ALL IN TABLESPACE

On 2015-12-14 20:44:20 +0900, Michael Paquier wrote: > + /* > + * ALTER TABLE,INDEX,MATERIALIZED VIEW ALL IN TABLESPACE xxx OWNED BY > xxx > + * SET TABLESPACE. > + */ > + else if (pg_strcasecmp(prev9_wd, "ALL") == 0 && > + pg_strcasecmp(prev8_wd, "IN")

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

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 >>

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

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

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

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

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

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

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

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

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

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

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

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 --help=variables lists variables that can't be set

2015-12-04 4:08 GMT+01:00 Peter Eisentraut : > psql --help=variables shows variables treated specially by psql. And it > tells you > > Usage: > psql --set=NAME=VALUE > or \set NAME VALUE > > But some of the variables listed cannot usefully be set, only read, such as > >

Re: [HACKERS] psql --help=variables lists variables that can't be set

On 2015-12-03 22:08:31 -0500, Peter Eisentraut wrote: > psql --help=variables shows variables treated specially by psql. And it > tells you > > Usage: > psql --set=NAME=VALUE > or \set NAME VALUE > > But some of the variables listed cannot usefully be set, only read, such as > > DBNAME

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

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

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

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

Re: [HACKERS] psql ignores failure to open -o target file

On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote: > On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote: > > I just noticed that parse_psql_options() ignores the result of > setQFout(), > > meaning that if the argument of a -o command line option is

Re: [HACKERS] psql ignores failure to open -o target file

"David G. Johnston" writes: > On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote: >> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote: >>> This seems surprising to me: any other program in the world would do >>> exit(1) after

Re: [HACKERS] psql ignores failure to open -o target file

I wrote: > I just noticed that parse_psql_options() ignores the result of setQFout(), > meaning that if the argument of a -o command line option is bogus, we'll > ignore the switch entirely after printing an error report. There's more silliness in the same area. \o with an invalid target spec is

Re: [HACKERS] psql ignores failure to open -o target file

On Wed, Dec 2, 2015 at 1:24 PM, Tom Lane wrote: > "David G. Johnston" writes: >> On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote: >>> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote: This seems

Re: [HACKERS] psql ignores failure to open -o target file

On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote: > I just noticed that parse_psql_options() ignores the result of setQFout(), > meaning that if the argument of a -o command line option is bogus, we'll > ignore the switch entirely after printing an error report. For example >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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 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

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

> 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?

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

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

Re: [HACKERS] psql completion for ids in multibyte string

Horiguchi-san, On 2015/11/05 18:10, Kyotaro HORIGUCHI wrote: > Hello. I don't know whether this is a bug fix or improvement, Would it be 50-50? :-) ... > > During the investigation into this issue, I found a mistake in > the comment for PQmblen. It give the byte length of the character > at

Re: [HACKERS] psql completion for ids in multibyte string

Hi. Thank you for the comments. The revised version is attaced. - A typo is fixed in the comment for PQmblen(). - Do the same fix to PQdsplen(). At Thu, 5 Nov 2015 18:32:59 +0900, Amit Langote wrote in <563b224b.3020...@lab.ntt.co.jp> > On 2015/11/05 18:10,

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

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

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

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.

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

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

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

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

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

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". > =#

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

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

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

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

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

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

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

On 2015-09-08 07:06:04 +0200, Pavel Stehule wrote: > 2015-09-07 21:44 GMT+02:00 Andres Freund : > > The spellings for boolean values were a relatively small subset of what > > the backend accepts - it's now on,off,true,false,yes,no,1,0. I'm not > > sure whether that's a good

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

Andres Freund wrote: > On 2015-09-08 07:06:04 +0200, Pavel Stehule wrote: > > 2015-09-07 21:44 GMT+02:00 Andres Freund : > > > The spellings for boolean values were a relatively small subset of what > > > the backend accepts - it's now on,off,true,false,yes,no,1,0. I'm not > >

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

2015-09-07 21:44 GMT+02:00 Andres Freund : > Hi, > > On 2015-09-02 22:58:21 +0200, Pavel Stehule wrote: > > > Won't that mean that enum variables don't complete to default anymore? > > > no, it does > > > > #define Query_for_enum \ > > " SELECT name FROM ( "\ > > " SELECT

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

Hi, On 2015-09-02 22:58:21 +0200, Pavel Stehule wrote: > > Won't that mean that enum variables don't complete to default anymore? > no, it does > > #define Query_for_enum \ > " SELECT name FROM ( "\ > " SELECT unnest(enumvals) AS name "\ > "FROM pg_catalog.pg_settings "\ > " WHERE

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

Hi 2015-09-02 15:23 GMT+02:00 Andres Freund : > Hi, > > On 2015-07-08 14:50:37 +0200, Pavel Stehule wrote: > > - static const char *const my_list[] = > > - {"DEFAULT", NULL}; > > + /* fallback for GUC settings */ > >

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

Hi, On 2015-07-08 14:50:37 +0200, Pavel Stehule wrote: > - static const char *const my_list[] = > - {"DEFAULT", NULL}; > + /* fallback for GUC settings */ > > - COMPLETE_WITH_LIST(my_list); > +

Re: [HACKERS] psql - better support pipe line

On Fri, Aug 28, 2015 at 9:52 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 8/28/15 3:58 AM, Shulgin, Oleksandr wrote: It occurs to me the most flexible thing that could be done here would be providing a libpq function that spits out JSON connection parameters and have psql

Re: [HACKERS] psql - better support pipe line

On 8/29/15 8:10 AM, Shulgin, Oleksandr wrote: The other issue is there's no way to capture \conninfo inside of psql and do something with it. If instead this was exposed as a variable, you could handle it in SQL if you wanted to. Yeah, I forgot about the variable proposal, that

Re: [HACKERS] psql - better support pipe line

On Fri, Aug 28, 2015 at 3:29 AM, Jim Nasby jim.na...@bluetreble.com wrote: On 8/27/15 8:37 AM, Pavel Stehule wrote: I don't think we can detect and remove the default values from this output in a reliable way? This is pretty difficult - any parameter can be important, and hard to

Re: [HACKERS] psql - better support pipe line

On 8/28/15 3:58 AM, Shulgin, Oleksandr wrote: It occurs to me the most flexible thing that could be done here would be providing a libpq function that spits out JSON connection parameters and have psql turn that into a variable. It would be easy to feed that to a SQL statement

<    1   2   3   4   5   6   7   8   9   10   >