Horton

Thread

  1. Parser abort ignoring following commands

    Peter Eisentraut <peter_e@gmx.net> — 2001-05-26T14:23:13Z

    psql -c 'select * from pg_class; select * from no_such_table;'

Shouldn't this at least give me the result of the first select before
aborting the second?  Moreover, shouldn't

psql -c 'select * from no_such_table; select * from pg_class;'

give me the result of the second select?

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

  2. Re: Parser abort ignoring following commands

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-26T15:12:31Z

    Peter Eisentraut <peter_e@gmx.net> writes:
> psql -c 'select * from pg_class; select * from no_such_table;'
> Shouldn't this at least give me the result of the first select before
> aborting the second?

The behavior you are complaining of is not the backend's fault.
The reason it acts that way is that psql is feeding the entire -c 
string to the backend as one query, and not paying any attention
to the possibility that multiple query results might be available
from the string.

It's a little bit inconsistent that psql feeds a -c string to the
backend as one query, whereas the same input line fed to it from a file
or terminal would be split into per-statement queries.  However,
I'd vote against changing it, since (a) you might break existing
applications that depend on this behavior, and (b) if you do that then
there will be no way to exercise multi-statement query strings from
psql.

It might possibly make sense for psql to stop using PQexec() but
instead use PQsendQuery() and PQgetResult(), so that it could
handle multiple results coming back from a single query string.
If you did that then the first example would work the way you want.

			regards, tom lane

  3. Re: Parser abort ignoring following commands

    Peter Eisentraut <peter_e@gmx.net> — 2001-05-26T15:31:28Z

    Tom Lane writes:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > psql -c 'select * from pg_class; select * from no_such_table;'
> > Shouldn't this at least give me the result of the first select before
> > aborting the second?
>
> The behavior you are complaining of is not the backend's fault.
> The reason it acts that way is that psql is feeding the entire -c
> string to the backend as one query, and not paying any attention
> to the possibility that multiple query results might be available
> from the string.

No, I think there is another problem.  How about something without
selects:

$ psql -c 'delete from pk; delete from xx;'
ERROR:  Relation 'xx' does not exist

"pk" exists, but nothing is deleted.

$ psql -c 'drop user joe; drop user foo;'
ERROR:  DROP USER: user "foo" does not exist

User "joe" exists, but it is not dropped.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

  4. Re: Parser abort ignoring following commands

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-26T15:36:54Z

    Peter Eisentraut <peter_e@gmx.net> writes:
> No, I think there is another problem.  How about something without
> selects:

> $ psql -c 'delete from pk; delete from xx;'
> ERROR:  Relation 'xx' does not exist

> "pk" exists, but nothing is deleted.

Sure, because the transaction is rolled back.  The whole string
is executed in one transaction.  You will definitely break existing
applications if you change that.

			regards, tom lane

  5. Re: Parser abort ignoring following commands

    Peter Eisentraut <peter_e@gmx.net> — 2001-05-26T15:57:16Z

    Tom Lane writes:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > No, I think there is another problem.  How about something without
> > selects:
>
> > $ psql -c 'delete from pk; delete from xx;'
> > ERROR:  Relation 'xx' does not exist
>
> > "pk" exists, but nothing is deleted.
>
> Sure, because the transaction is rolled back.  The whole string
> is executed in one transaction.  You will definitely break existing
> applications if you change that.

Applications that rely on this behaviour are broken.  It was always said
that statements are in their own transaction block unless in an explicit
BEGIN/COMMIT block.  A statement is defined to end at the semicolon, not
at the end of the string you submit to PQexec().

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

  6. Re: Parser abort ignoring following commands

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-26T16:14:52Z

    Peter Eisentraut <peter_e@gmx.net> writes:
>> Sure, because the transaction is rolled back.  The whole string
>> is executed in one transaction.  You will definitely break existing
>> applications if you change that.

> Applications that rely on this behaviour are broken.  It was always said
> that statements are in their own transaction block unless in an explicit
> BEGIN/COMMIT block.  A statement is defined to end at the semicolon, not
> at the end of the string you submit to PQexec().

Au contraire: single query strings have always been executed as single
transactions.  Whether that would be the most consistent behavior in a
green field is quite irrelevant.  We *cannot* change it now, or we will
break existing applications --- silently.

If you can find something in the documentation that states what you
claim is the definition, I'll gladly change it ;-).

			regards, tom lane

  7. Re: Parser abort ignoring following commands

    Hannu Krosing <hannu@tm.ee> — 2001-05-26T18:50:58Z

    Peter Eisentraut wrote:
> 
> Tom Lane writes:
> 
> > Peter Eisentraut <peter_e@gmx.net> writes:
> > > No, I think there is another problem.  How about something without
> > > selects:
> >
> > > $ psql -c 'delete from pk; delete from xx;'
> > > ERROR:  Relation 'xx' does not exist
> >
> > > "pk" exists, but nothing is deleted.
> >
> > Sure, because the transaction is rolled back.  The whole string
> > is executed in one transaction.  You will definitely break existing
> > applications if you change that.
> 
> Applications that rely on this behaviour are broken.  It was always said
> that statements are in their own transaction block unless in an explicit
> BEGIN/COMMIT block.  A statement is defined to end at the semicolon, not
> at the end of the string you submit to PQexec().

I guess that this is a multi-command statement ?

It has always been so, except that psql seems to do some parsing and
issue 
each command to backend separately.

----------------
Hannu

  8. Re: Parser abort ignoring following commands

    Adam Haberlach <adam@newsnipple.com> — 2001-05-27T02:00:44Z

    On Sat, May 26, 2001 at 05:57:16PM +0200, Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > Peter Eisentraut <peter_e@gmx.net> writes:
> > > No, I think there is another problem.  How about something without
> > > selects:
> >
> > > $ psql -c 'delete from pk; delete from xx;'
> > > ERROR:  Relation 'xx' does not exist
> >
> > > "pk" exists, but nothing is deleted.
> >
> > Sure, because the transaction is rolled back.  The whole string
> > is executed in one transaction.  You will definitely break existing
> > applications if you change that.
> 
> Applications that rely on this behaviour are broken.  It was always said
> that statements are in their own transaction block unless in an explicit
> BEGIN/COMMIT block.  A statement is defined to end at the semicolon, not
> at the end of the string you submit to PQexec().

	You put semicolons at the end of your strings to PQexec()?

-- 
Adam Haberlach            | At either end of the social spectrum there lies
adam@newsnipple.com       | a leisure class.  -- Eric Beck 1965 
http://www.newsnipple.com |
'88 EX500    '00 >^<      | http://youlook.org