From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, Vik Fearing <vik(at)postgresfriends(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal \gcsv |
Date: | 2020-04-03 20:21:30 |
Message-ID: | CAFj8pRB3Pahs3c9qVa+eSTgL8vMbN5jwi6kbjTB3K-T4n6VEPA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
st 1. 4. 2020 v 18:29 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 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.
>
The stack idea probably needs much stronger psql handling error redesign to
be safe
postgres=# \set ON_ERROR_STOP 1
postgres=# select 10/0 \echo 'ahoj' \g \echo 'nazdar
ahoj
ERROR: division by zero
There is not guaranteed so the command for returning to stored state will
be executed.
> However, if we prefer something closer to Plan A ... I took a look at
> the psql lexer, and the only difference between OT_FILEPIPE and OT_NORMAL
> parsing is if the argument starts with '|'. So we could make it work
> I think. 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, and require a value for each
> pset-option (no fair using the shortcuts like "\pset expanded"). Then
> it's easy to separate the option names and values from the paren markers.
> The \g parser would consume its first argument in OT_FILEPIPE mode, and
> then if it sees '(' it would consume arguments in OT_NORMAL mode until
> it's found the ')'.
>
To have this syntax can be nice, but the requirement spaces around
parenthesis is not too user friendly and natural.
Following ideas are based on Tom's ideas
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] .. prepare and set copy of current print
setting for next execution command
\pset main
\pset reset .. reset to defaults
so this can support some scenarios
-- one shot csv
\pset oneshot -- copy current settings to one shot environment and use one
shot environment
\pset format csv
\pset csv_delimiter ;
select 1; -- any output
-- prepare named configuration
\pset oneshot
\pset format csv
\pset csv_delimiter ;
\pset save czech_csv -- serialize changes against "main" environment
\pset main
\pset load czech_csv
select 1;
or
\pset oneshot czech_csv
select 1;
So we just need to enhance syntax only of \pset command, and we have to
support work with two print settings environments - "main" and "oneshot"
What do you think about this proposal?
Regards
Pavel
> This way also narrows the backwards-compatibility problem from "fails if
> your filename starts with '('" to "fails if your filename is exactly '('",
> which seems acceptably improbable to me.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2020-04-03 20:44:11 | Re: Binary support for pgoutput plugin |
Previous Message | Robert Haas | 2020-04-03 19:53:06 | Re: backup manifests |