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

From Catalin Iacob
Subject Re: proposal: multiple psql option -c
Date
Msg-id CAHg_5gqds7ipWwykyrMpes_4ZXjyBPLT9PtMWqKzOn5MUK-L9Q@mail.gmail.com
Whole thread Raw
In response to Re: proposal: multiple psql option -c  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: proposal: multiple psql option -c  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: proposal: multiple psql option -c  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Sun, Nov 15, 2015 at 3:53 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> I suggest you review the original thread on this subject before a line was
> ever written. "multiple" (see subject line on this whole thread) is clearly
> what is being asked for. Making people turn that into a single argument is
> not what was envisaged. See for example Pavel's original example involving
> use of xargs where that's clearly not at all easy.

I couldn't see why it would matter to have multiple -C, but xargs
having -n which consumes more than 1 stdin item is indeed an use case.
When reading the thread I didn't notice it since I didn't know what -n
does.

But multiple -C is confusing since it suggests the groupings matter.

To me at least, it feels weird that -C "SELECT 1; SELECT 2;" -C
"SELECT 3;" is the same as -C "SELECT 1; SELECT 2; SELECT 3" and lots
of other combinations. It feels like the split in groups must mean
something, otherwise why would you support/use multiple groups?

Upthread at least somebody thought each -C group would/should be a
transaction and I can see this confusion coming up again and again,
enough to question whether this patch is an improvement over the
current situation. And if a single -C is too small of an improvement,
maybe it means the whole idea should be dropped. I think the same of
multiple -f as well: to me they're more confusing than helpful for the
same reason.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Tom Lane
Date:
Subject: Re: check for interrupts in set_rtable_names