On 11/17/2015 04:13 PM, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
A few years ago there was a proposal to not only allow multiple -c
options, but to allow -c and -f to be intermingled. This seems really
rather useful; I'd like to be able to type psql -c do_this_first -f
script.sql and have that work. But of course it's kind of hard to
figure out how that should behave given the various differences
between -c and -f.
Hm. That's actually a good reason for changing -c, I guess. (Or else
introducing a -C that is compatible with -f, but I agree that that
seems a bit ugly.)
If we made -c handle its input just like it had come from a file,
then what would we need to explain to people that wanted the old
behavior? I guess we'd need to tell them to use --no-psqlrc and
--single-transaction at least, and "-v ON_ERROR_STOP=1". And
even then it wouldn't replicate the behavior of discarding all
but the last command output. (Maybe nobody out there is relying
on that, but I wouldn't bet on it.) And that's all still assuming
that they don't care about multi-command-per-PQexec in itself, but
only the easily user-visible differences.
So that is kind of looking like a mess, and 90% of the mess is from
not wanting to use a PQexec per -c switch, which if you ask me is
not very much of the value-add here. AFAICS the only thing that's
really in conflict with -f is the implied --no-psqlrc. How about
this design:
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.
As long as you put only one SQL command per -c, I don't think that
this definition has any real surprises. And we can discourage
people from putting more than one, saying that that will invoke
legacy behaviors you probably don't want.
WFM. The only reason I originally suggested -C was to avoid
compatibility issues. If we're prepared to take that on then I agree
it's better to do what you suggest.
I assume that we won't have any great difficulty in handling
intermingled -c and -f options in the correct order. Essentially I think
we'll have to have a unified list of such arguments.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
