On 11/17/2015 04:13 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@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
