Re: proposal \gcsv - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: proposal \gcsv |
| Date | |
| Msg-id | CAFj8pRB3Pahs3c9qVa+eSTgL8vMbN5jwi6kbjTB3K-T4n6VEPA@mail.gmail.com Whole thread Raw |
| In response to | Re: proposal \gcsv (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: proposal \gcsv
(Tom Lane <tgl@sss.pgh.pa.us>)
|
| List | pgsql-hackers |
st 1. 4. 2020 v 18:29 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.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
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
pgsql-hackers by date: