Re: proposal: multiple psql option -c - Mailing list pgsql-hackers

From Catalin Iacob
Subject Re: proposal: multiple psql option -c
Date
Msg-id CAHg_5gpGQ9SVa7SWYmgq2auUcLaWkYy0yK0mRf2sHPxRFbPtqw@mail.gmail.com
Whole thread Raw
In response to Re: proposal: multiple psql option -c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal: multiple psql option -c  (Catalin Iacob <iacobcatalin@gmail.com>)
List 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 by date:

Previous
From: Torsten Zühlsdorff
Date:
Subject: Re: Extracting fields from 'infinity'::TIMESTAMP[TZ]
Next
From: Robert Haas
Date:
Subject: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)