Re: proposal: multiple psql option -c

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Catalin Iacob <iacobcatalin(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, dinesh kumar <dineshkumar02(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: multiple psql option -c
Date: 2015-11-17 22:51:12
Message-ID: 564BAF60.3000104@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-11-17 23:00:20 Re: [COMMITTERS] pgsql: Cause TestLib.pm to define $windows_os in all branches.
Previous Message Thom Brown 2015-11-17 21:59:21 Re: [DESIGN] ParallelAppend