Hi all

I've been working in psql a lot recently, and have started to wonder why statements with syntax errors or other problems that render them unexecutable terminate the transaction.

I understand why statements that raise errors during their execution terminate a transaction, and that explicit savepoints may be used if this is undesired. That's all good, and I know that ON_ERROR_ROLLBACK=interactive provides a helper for that in psql.

Savepoints are overhead, though, and I don't understand why they're required for statements that don't even parse. If I typo a statement and run:

   SELETC blah FROM blah;

why is a savepoint required to stop that from terminating the transaction? I know psql isn't parsing and validating the statements so bad statements still go to the backend, of course, but I don't get why the backend can't recognise an unparseable statement or statement that references non-existent database objects and report it without killing the transaction if it's talking to psql interactively.

Is this just a "nobody's cared enough to implement it" thing, where it'd be possible but the simplest/safest/easiest path is to have the backend always kill the tx and nobody's wanted to add a communication channel to let psql tell the backend it's working interactively?

--
Craig Ringer

POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088     Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to