Feature discussion: Should syntax errors abort a transaction?

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/