Re: proposal \gcsv

so 4. 4. 2020 v 0:24 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 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] .. prepare and set copy of current print
> > setting for next execution command
> > \pset main
> > \pset reset .. reset to defaults
>
> I feel like that's gotten pretty far away from the idea of a simple,
> easy-to-use way of adjusting the parameters for one \g operation.
> There'd be a whole lot of typing involved above and beyond the
> obviously-necessary part of specifying the new pset parameter values.
>

for my original proposal is important only one command \pset oneshot

so one shot setting can be done by

\pset oneshot
\pset format csv
\pset csv_separator ;
any command that print tuples

this is your plan B, but we we need just enhance only pset command, and all
others can be used without any modifications.

> (Also, it's not clear to me how that's any more robust than the
> stack idea. If you could lose "\pset pop" to an error, you could
> lose "\pset reset" too.)
>

The \pset reset should not to do switch from one shot to usual settings
(this is not necessary,because one shot settings is destroyed after
execution), but my idea is reset to initial psql settings

>
> If people are upset about the extra whitespace in the paren-style
> proposal, we could do without it. The only real problem would be
> if there's ever a pset parameter for which a trailing right paren
> could be a sensible part of the value. Maybe that's not ever
> going to be an issue; or maybe we could provide a quoting mechanism
> for weird pset values.
>

Parametrization in parenthesis is usual pattern (EXPLAIN, COPY, ..) in
Postgres, and for me it most natural syntax.

>
> regards, tom lane
>