Re: Feature discussion: Should syntax errors abort a transaction? - Mailing list pgsql-general

From Gavin Flower
Subject Re: Feature discussion: Should syntax errors abort a transaction?
Date
Msg-id 4FE0E0AF.1020803@archidevsys.co.nz
Whole thread Raw
In response to Re: Feature discussion: Should syntax errors abort a transaction?  (Rafal Pietrak <rafal@zorro.isa-geek.com>)
List pgsql-general

On 20/06/12 01:35, Rafal Pietrak wrote:
On Tue, 2012-06-19 at 19:06 +0800, Craig Ringer wrote:
On 06/19/2012 02:20 PM, Tom Lane wrote:
So you're suggesting that "SELECT 1/0;" should terminate a transaction,
but "SELECT 1//0;" should not?  How about "ROLBACK;"?  It gets pretty
squishy pretty fast when you try to decide which sorts of errors are
more important than others.

When put that way, it seems blindingly obvious. You have a talent for 
making a devastating point very succinctly.
I'd humbly disagree.

Not to drag this discussiong any further, just to make a point that the
other approach is also "blindingly obvious". Only the other way around.

The point is, that SQL syntax errors are so obviusly different from
execution errors, that noting this distinction should not raise any
ambiguity. In Tom's example "ROLBACK":
1. should not break the transaction
2. should only raise NOTICE: "syntax error"
2.1. in case this was issued from command line - user can always
ROL<TAB> to see what's next.
2.2. in case of a compiled program sending a "ROLBACK" to the
backend .... hack, the programmer should know better.
3. and BTW: what about rolling back a tediously cooked sequence of
statements finished by "COMINT"?

Things are not so obvious. And frankly, if not for the "<TAB>" I'd have
case (3) so often, that it would have driven me crasy.


-R

--
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/



I would be be extremely concerned about any move to allow syntax errors not to abort a transaction.

Even minor syntax errors may indicate that something much more serious is wrong.

PL/1 was designed to tolerate various errors and guess what the programmer intended, it would make assumptions and act on them – a good way to hide serious programming errors.

A language that is too forgiving encourages sloppy thinking.

A bit like in chess, if you don't follow the dictum of 'touch a piece move it' in social play (it is the rule in match and tournament play), then your level of skill in Chess is unlikely to improve much. I coach Chess at my son's school and I used to be Director-of-Play for Chess tournaments.

I remember learning C many years ago, very unforgiving. However, the discipline imposed was very beneficial to improving my programming skills.

I would far rather a compiler pull me up for minor violations, than an obvious error not picked up until I came to test the program. The compiler is not perfect and some errors will slip through. However, the sooner errors are detected, the less likely an error will cause bad problems in production.

The greater the size and complexity of code, the more important this all becomes. Mind you, even very simple SQL SELECT's might have results used to make critical business decisions - so even then, sloppy habits should be discouraged.

I would be very reluctant to hire any developer who had the mind set of seriously wanting something like psql to be forgiving of any kind of error - as it suggests that they are more careless than normal, and lack the attitude to be reliably rigorous.


pgsql-general by date:

Previous
From: Darren Duncan
Date:
Subject: Re: Feature discussion: Should syntax errors abort a transaction?
Next
From: "Dickson S. Guedes"
Date:
Subject: Re: pgstat wait timeout : permission denied