Re: proposal \gcsv

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
>

In response to

Responses

Browse pgsql-hackers by date

  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