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

From Andrew Dunstan
Subject Re: proposal: multiple psql option -c
Date
Msg-id 564A613B.40407@dunslane.net
Whole thread Raw
In response to Re: proposal: multiple psql option -c  (Catalin Iacob <iacobcatalin@gmail.com>)
Responses Re: proposal: multiple psql option -c
List pgsql-hackers

On 11/16/2015 11:16 AM, Catalin Iacob wrote:
> 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.
>


I honestly don't see what's so confusing about it, and if there is any 
confusion then surely we could make sure what's happening is well 
documented.

cheers

andrew



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] SQL function to report log message
Next
From: Robert Haas
Date:
Subject: Re: [DESIGN] ParallelAppend