Re: proposal \gcsv

2020-04-07 Thread Pavel Stehule
út 7. 4. 2020 v 23:47 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > út 7. 4. 2020 v 19:27 odesílatel Tom Lane napsal: > >> Considering this is the last day before v13 feature freeze, should > >> I push this, or sit on it till v14? I feel reasonably good that we > >> have a nice featu

Re: proposal \gcsv

2020-04-07 Thread Tom Lane
Pavel Stehule writes: > út 7. 4. 2020 v 19:27 odesílatel Tom Lane napsal: >> Considering this is the last day before v13 feature freeze, should >> I push this, or sit on it till v14? I feel reasonably good that we >> have a nice feature definition here, but it's awfully late in the >> cycle to b

Re: proposal \gcsv

2020-04-07 Thread Pavel Stehule
út 7. 4. 2020 v 19:27 odesílatel Tom Lane napsal: > Here's a more fully fleshed-out patch, with documentation and some > test cases. (0001 patch is identical to last time.) > > Considering this is the last day before v13 feature freeze, should > I push this, or sit on it till v14? I feel reason

Re: proposal \gcsv

2020-04-07 Thread Tom Lane
Here's a more fully fleshed-out patch, with documentation and some test cases. (0001 patch is identical to last time.) Considering this is the last day before v13 feature freeze, should I push this, or sit on it till v14? I feel reasonably good that we have a nice feature definition here, but it

Re: proposal \gcsv

2020-04-07 Thread Pavel Stehule
út 7. 4. 2020 v 16:28 odesílatel Tom Lane napsal: > Isaac Morland writes: > > On Tue, 7 Apr 2020 at 03:30, Pavel Stehule > wrote: > >> your patch supports syntax > >> (option1=value option2=value) > >> It looks little bit inconsistent and unusual > > > It's the same as a connection string. > >

Re: proposal \gcsv

2020-04-07 Thread Tom Lane
Isaac Morland writes: > On Tue, 7 Apr 2020 at 03:30, Pavel Stehule wrote: >> your patch supports syntax >> (option1=value option2=value) >> It looks little bit inconsistent and unusual > It's the same as a connection string. Yeah, I didn't exactly invent that out of nowhere. There are a couple

Re: proposal \gcsv

2020-04-07 Thread Pavel Stehule
út 7. 4. 2020 v 12:49 odesílatel Isaac Morland napsal: > On Tue, 7 Apr 2020 at 03:30, Pavel Stehule > wrote: > > >> your patch supports syntax >> >> (option1=value option2=value) >> >> It looks little bit inconsistent and unusual >> >>> > It's the same as a connection string. Actually, maybe tha

Re: proposal \gcsv

2020-04-07 Thread Isaac Morland
On Tue, 7 Apr 2020 at 03:30, Pavel Stehule wrote: > your patch supports syntax > > (option1=value option2=value) > > It looks little bit inconsistent and unusual > >> It's the same as a connection string. Actually, maybe that's the key to allowing parentheses, etc. in option values if needed - a

Re: proposal \gcsv

2020-04-07 Thread Pavel Stehule
út 7. 4. 2020 v 2:28 odesílatel Tom Lane napsal: > Here's a WIP patch for the parenthesized-options route. > > I realized that if we make the options be single words in the form > name=value, we can easily handle the shortcut forms with no value. > So that's what this does. > > What this does *no

Re: proposal \gcsv

2020-04-06 Thread Tom Lane
Here's a WIP patch for the parenthesized-options route. I realized that if we make the options be single words in the form name=value, we can easily handle the shortcut forms with no value. So that's what this does. What this does *not* do is offer any solution to the question of how to put a rig

Re: proposal \gcsv

2020-04-03 Thread Pavel Stehule
so 4. 4. 2020 v 0:24 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > We can have a new commands for cloning print environments and switch to > one > > shot environment. It can be based just on enhancing of \pset command > > > \pset save anyidentifier .. serialize settings > > \pset load

Re: proposal \gcsv

2020-04-03 Thread Tom Lane
Pavel Stehule writes: > We can have a new commands for cloning print environments and switch to one > shot environment. It can be based just on enhancing of \pset command > \pset save anyidentifier .. serialize settings > \pset load anyidentifier .. load setting > \pset oneshot [anyidentifer] ..

Re: proposal \gcsv

2020-04-03 Thread Pavel Stehule
st 1. 4. 2020 v 18:29 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > It can work, but it is not user friendly - my proposal was motivated by > > using some quick csv exports to gplot's pipe. > > I kind of liked the stack idea, myself. It's simpler than what I was > suggesting and it co

Re: proposal \gcsv

2020-04-02 Thread Daniel Verite
Alvaro Herrera wrote: > Can we fix that by adding some syntax to allow command aliases? > So you could add to your .psqlrc something like > > \alias \gcsv \pset push all \; \cbuf; \; \pset pop > > where the \cbuf is a hypothetical "function" that expands to the current > query buffer. T

Re: proposal \gcsv

2020-04-01 Thread Vik Fearing
On 4/1/20 6:29 PM, Tom Lane wrote: > I'd modify my first proposal so far as to make it > > \g ( pset-option pset-value ... ) filename-or-pipe > > That is, require spaces around the parens I think requiring spaces inside the parentheses is a severe POLA violation and I vote strongly against

Re: proposal \gcsv

2020-04-01 Thread Alvaro Herrera
On 2020-Apr-01, Pavel Stehule wrote: > It can work, but it is not user friendly - my proposal was motivated by > using some quick csv exports to gplot's pipe. Can we fix that by adding some syntax to allow command aliases? So you could add to your .psqlrc something like \alias \gcsv \pset push a

Re: proposal \gcsv

2020-04-01 Thread Tom Lane
Pavel Stehule writes: > It can work, but it is not user friendly - my proposal was motivated by > using some quick csv exports to gplot's pipe. I kind of liked the stack idea, myself. It's simpler than what I was suggesting and it covers probably 90% of the use-case. However, if we prefer somet

Re: proposal \gcsv

2020-04-01 Thread Pavel Stehule
st 1. 4. 2020 v 17:52 odesílatel Daniel Verite napsal: > Tom Lane wrote: > > > I could see having a command to copy the current primary formatting > > parameters to the alternate area, too. > > We could have a stack to store parameters before temporary > changes, for instance if you want

Re: proposal \gcsv

2020-04-01 Thread Isaac Morland
On Wed, 1 Apr 2020 at 11:52, Daniel Verite wrote: > Tom Lane wrote: > > > I could see having a command to copy the current primary formatting > > parameters to the alternate area, too. > > We could have a stack to store parameters before temporary > changes, for instance if you want to d

Re: proposal \gcsv

2020-04-01 Thread Daniel Verite
Tom Lane wrote: > I could see having a command to copy the current primary formatting > parameters to the alternate area, too. We could have a stack to store parameters before temporary changes, for instance if you want to do one csv export and come back to normal without assuming what "

Re: proposal \gcsv

2020-04-01 Thread Tom Lane
Vik Fearing writes: > On 4/1/20 1:53 AM, Tom Lane wrote: >> Consider some syntax along the lines of >> \gpset (pset-option-name [pset-option-value]) ... filename > If parens are going to be required, why don't we just add them to \g? > TABLE blah \g (format csv) filename Yeah, if we're willing t

Re: proposal \gcsv

2020-04-01 Thread Vik Fearing
On 4/1/20 1:53 AM, Tom Lane wrote: > Consider some syntax along the lines of > > \gpset (pset-option-name [pset-option-value]) ... filename > > or if you don't like parentheses, choose some other punctuation to wrap > the \pset options in. I initially thought of square brackets, but I'm > afraid

Re: proposal \gcsv

2020-03-31 Thread Tom Lane
I took a look at this proposal, and while I see the value of being able to do something like this, it seems pretty short-sighted and non-orthogonal as it stands. We've already got \gx, which is a wart, and now this patch wants to add \gfmt which is a different wart of the same ilk. What happens i

Re: proposal \gcsv

2020-03-28 Thread Erik Rijkers
On 2020-03-28 15:06, Daniel Verite wrote: Erik Rijkers wrote: 2. let the psql command-line option '--csv' honour the value given by psql -F/--field-separator (it does not do so now) or 3. add an psql -commandline option: --csv-field-separator Setting the field separator on the command l

Re: proposal \gcsv

2020-03-28 Thread Pavel Stehule
so 28. 3. 2020 v 15:06 odesílatel Daniel Verite napsal: > Erik Rijkers wrote: > > > 2. let the psql command-line option '--csv' honour the value given by > > psql -F/--field-separator (it does not do so now) > > > > or > > > > 3. add an psql -commandline option: > > --csv-field-separa

Re: proposal \gcsv

2020-03-28 Thread Daniel Verite
Erik Rijkers wrote: > 2. let the psql command-line option '--csv' honour the value given by > psql -F/--field-separator (it does not do so now) > > or > > 3. add an psql -commandline option: > --csv-field-separator Setting the field separator on the command line is already supporte

Re: proposal \gcsv

2020-03-27 Thread Pavel Stehule
čt 26. 3. 2020 v 19:41 odesílatel Erik Rijkers napsal: > On 2020-03-26 18:49, Pavel Stehule wrote: > > Hi > > > > [psql-gfmt.patch] > > This seems useful and works well; I haven't found any errors. Well done. > > However, I have a suggestion that is perhaps slightly outside of this > patch but fu

Re: proposal \gcsv

2020-03-26 Thread Erik Rijkers
On 2020-03-26 18:49, Pavel Stehule wrote: Hi [psql-gfmt.patch] This seems useful and works well; I haven't found any errors. Well done. However, I have a suggestion that is perhaps slightly outside of this patch but functionally so close that maybe we can discuss it here. When you try to g

Re: proposal \gcsv

2020-03-26 Thread Pavel Stehule
čt 26. 3. 2020 v 18:55 odesílatel Vik Fearing napsal: > On 3/26/20 10:49 AM, Pavel Stehule wrote: > > Hi > > > > čt 26. 3. 2020 v 17:45 odesílatel Vik Fearing > > napsal: > > > >> After some opinions on the first issue and fixing the second, I think > >> this is good to be committed. > >> > > >

Re: proposal \gcsv

2020-03-26 Thread Vik Fearing
On 3/26/20 10:49 AM, Pavel Stehule wrote: > Hi > > čt 26. 3. 2020 v 17:45 odesílatel Vik Fearing > napsal: > >> After some opinions on the first issue and fixing the second, I think >> this is good to be committed. >> > > Thank you for review This patch now looks good to me. Marking as Ready

Re: proposal \gcsv

2020-03-26 Thread Pavel Stehule
Hi čt 26. 3. 2020 v 17:45 odesílatel Vik Fearing napsal: > On 3/24/20 3:02 AM, Pavel Stehule wrote: > > Hi > > > > rebase > > Thank you, Pavel. > > I have now had time to review it, and it looks good to me except for two > issues. > > The first is, even though I suggested gf, I think it should a

Re: proposal \gcsv

2020-03-26 Thread Vik Fearing
On 3/24/20 3:02 AM, Pavel Stehule wrote: > Hi > > rebase Thank you, Pavel. I have now had time to review it, and it looks good to me except for two issues. The first is, even though I suggested gf, I think it should actually be gfmt. There may be something else in the future that starts with f

Re: proposal \gcsv

2020-03-24 Thread Pavel Stehule
Hi rebase Regards Pavel diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml index 402c4b1b26..429e0d5708 100644 --- a/doc/src/sgml/ref/psql-ref.sgml +++ b/doc/src/sgml/ref/psql-ref.sgml @@ -2199,6 +2199,16 @@ CREATE INDEX + +\gf format [

Re: proposal \gcsv

2020-03-01 Thread Vik Fearing
On 01/03/2020 13:29, Pavel Stehule wrote: > so 29. 2. 2020 v 11:34 odesílatel Vik Fearing > napsal: > >> On 29/02/2020 06:43, Pavel Stehule wrote: >>> Hi >>> >>> I would to enhance \g command about variant \gcsv >>> >>> proposed command has same behave like \g, only the result will be every >>> t

Re: proposal \gcsv

2020-03-01 Thread Pavel Stehule
so 29. 2. 2020 v 18:06 odesílatel David Fetter napsal: > On Sat, Feb 29, 2020 at 11:59:22AM +0100, Pavel Stehule wrote: > > so 29. 2. 2020 v 11:34 odesílatel Vik Fearing > > napsal: > > > > > On 29/02/2020 06:43, Pavel Stehule wrote: > > > > Hi > > > > > > > > I would to enhance \g command about

Re: proposal \gcsv

2020-03-01 Thread Pavel Stehule
so 29. 2. 2020 v 11:34 odesílatel Vik Fearing napsal: > On 29/02/2020 06:43, Pavel Stehule wrote: > > Hi > > > > I would to enhance \g command about variant \gcsv > > > > proposed command has same behave like \g, only the result will be every > > time in csv format. > > > > It can helps with writ

Re: proposal \gcsv

2020-02-29 Thread David Fetter
On Sat, Feb 29, 2020 at 11:59:22AM +0100, Pavel Stehule wrote: > so 29. 2. 2020 v 11:34 odesílatel Vik Fearing > napsal: > > > On 29/02/2020 06:43, Pavel Stehule wrote: > > > Hi > > > > > > I would to enhance \g command about variant \gcsv > > > > > > proposed command has same behave like \g, onl

Re: proposal \gcsv

2020-02-29 Thread Pavel Stehule
so 29. 2. 2020 v 11:34 odesílatel Vik Fearing napsal: > On 29/02/2020 06:43, Pavel Stehule wrote: > > Hi > > > > I would to enhance \g command about variant \gcsv > > > > proposed command has same behave like \g, only the result will be every > > time in csv format. > > > > It can helps with writ

Re: proposal \gcsv

2020-02-29 Thread Vik Fearing
On 29/02/2020 06:43, Pavel Stehule wrote: > Hi > > I would to enhance \g command about variant \gcsv > > proposed command has same behave like \g, only the result will be every > time in csv format. > > It can helps with writing psql macros wrapping \g command. > > Options, notes? But then we

proposal \gcsv

2020-02-28 Thread Pavel Stehule
Hi I would to enhance \g command about variant \gcsv proposed command has same behave like \g, only the result will be every time in csv format. It can helps with writing psql macros wrapping \g command. Options, notes? Regards Pavel