Re: Alternative to psql -c ?

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

In response to

Responses

Browse pgsql-general by date

  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 ?