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

From Catalin Iacob
Subject Re: proposal: multiple psql option -c
Date
Msg-id CAHg_5godKAaTYzfPOVrwWL42nvqj2thxy2mYwSqthN4eR9jJ1g@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  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Sun, Nov 15, 2015 at 1:27 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> That seems to me to get rid of the main motivation for this change, which is
> to allow multiple such arguments, which together would as as if they were
> all written to a file which was then invoked like -f file.

It seems to me the motivation is not "multiple command line arguments"
but sending multiple statements to the backend in one psql invocation
without needing bash specific here docs or a temporary file for -f.
Most combinations of such multiple statements can already be sent via
-c which sends them in one query, the backend executes them in one
transaction but the backend rejects some combinations like SELECT +
VACUUM.

I think the proposal was mislead by the apparent similarity with -c
and said "if -c can't do SELECT + VACUUM let's do a sort of repeated
-c and call that -C SELECT -C VACUUM". But why not do the same with -C
"SELECT 1; VACUUM" which works just like having a file with that
content works today but handier for scripts? Doesn't this solve the
exact need in this thread?

I'm arguing that sending multiple statements and executing each in one
transaction (the current proposed semantics of -C) is not like -c and
doesn't need to be "repeated -c" it's exactly like reading stdin or
file passed to -f and solves the original problem.But maybe I'm
missing something.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_stat_statements query jumbling question
Next
From: Robert Haas
Date:
Subject: Re: Proposal: "Causal reads" mode for load balancing reads without stale data