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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
