Re: proposal: multiple psql option -c

Поиск
Список
Период
Сортировка
От Catalin Iacob
Тема Re: proposal: multiple psql option -c
Дата
Msg-id CAHg_5gpGQ9SVa7SWYmgq2auUcLaWkYy0yK0mRf2sHPxRFbPtqw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: multiple psql option -c  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: multiple psql option -c
Список pgsql-hackers
On Tue, Nov 17, 2015 at 10:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 1. -c no longer implies --no-psqlrc.  That's a backwards incompatibility,
> but very easy to explain and very easy to work around.
>
> 2. You can have multiple -c and/or -f.  Each -c is processed in
> the traditional way, ie, either it's a single backslash command
> or it's sent in a single PQexec.  That doesn't seem to me to have
> much impact on the behavior of adjacent -c or -f.
>
> 3. If you combine -1 with -c and/or -f, you get one BEGIN inserted
> at the beginning and one COMMIT at the end.  Nothing else changes.

And -v AUTOCOMMIT=off should do the same as now for -c: issue a BEGIN
before each single PQexec with the content of each -c.

I like it, it avoids what I didn't like about -C semantics since the
grouping now means something (single PQexec per group) and you even
see the effects of the grouping in the result (only last result of
group is returned). If you don't like that grouping (probably most
people won't) the solution is intuitive: split the group to multiple
-c.

Another incompatibility is that -1 is now silently ignored by -c so
for example psql -1 -c VACUUM now works and it won't work with the new
semantics. But this seems like a good thing because it reflects that
VACUUM doesn't work in a transaction so I don't think it should stop
this proposal from going ahead.

I'll try to write the documentation patch for these semantics sometime
next week.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Torsten Zühlsdorff
Дата:
Сообщение: Re: Extracting fields from 'infinity'::TIMESTAMP[TZ]
Следующее
От: Robert Haas
Дата:
Сообщение: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)