From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | James Le Cuirot <chewi(at)aura-online(dot)co(dot)uk> |
Cc: | hubert depesz lubaczewski <depesz(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Alternative to psql -c ? |
Date: | 2014-06-25 16:04:44 |
Message-ID: | 75889.1403712284@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
James Le Cuirot <chewi(at)aura-online(dot)co(dot)uk> writes:
> hubert depesz lubaczewski <depesz(at)gmail(dot)com> wrote:
>> Perhaps you can explain what is the functionality you want to
>> achieve, as I, for one, don't understand. Do you want transactions?
>> Or not?
> I want an implicit transaction around the whole script if no explicit
> transactions are present in the script. This is what psql's -c option
> does and this is also what the pg gem does because both use PQexec.
Well, psql -c (and also multiple commands in PQexec) have more odd
behaviors than that. Notably, any error causes abandonment of the *whole*
string, even if it's got begin/end commands in it.
Most people think that psql -c's behavior is a legacy thing that we ought
to change someday; if backwards compatibility weren't such a big deal
around here, we might've done it already. You can find multiple bugs in
the pgsql-bugs archives that amount to complaints that psql -c ought to
work more like reading from stdin or a file. I don't think it's a good
idea for you to try to arrange things so that untold amounts of code is
depending on that behavior never changing.
In short, I think it would be good to push back on the way Chef is doing
things now, not perpetuate a dependency on a legacy behavior.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2014-06-25 18:20:32 | Re: Extended Prefetching using Asynchronous IO - proposal and patch |
Previous Message | Jerry Sievers | 2014-06-25 15:34:57 | Re: Alternative to psql -c ? |