so 4. 4. 2020 v 0:24 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.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.
