Re: Feature discussion: Should syntax errors abort a transaction?

On Wed, 2012-06-20 at 08:27 +1200, Gavin Flower wrote:
[----------------]
> > >
> >
> >
> I would be be extremely concerned about any move to allow syntax
> errors not to abort a transaction.

Me too. But it's a nuicence for interractive session when  transactions
breakes due to syntax error - still, may be as Rainer Pruy said earlier,
this may be a suggestion to maintainers of interactive tools.
>
> Even minor syntax errors may indicate that something much more serious
> is wrong.

No. We are talking about an interactive session - someone just have
misstyped something; it's a one time event.
>
> 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.

This is "dangerous grounds" :) - without going too far I'd say, there is
also ADA (rigorious) and perl (sloopy). "statistically", anything I
installed, that's written in perl is ways more stable, then enything
else.

But I'd also say, that I prefere tools (programming languages, operating
systems, IDE, etc), that help me from makeing errors.
>
[-----------]
>
> 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.

On the other hand I find it more tedious then it pays off, when current
CC force me to explicitly typecast every pointer I write, because: "type
don't match". But that's not the point here.

The point is, that sometimes we need regorious, and sometimes we need
sloopy. Like, when we start a project, we need to "scetch", then we need
to "tighten the shoelaces". At least for me it works that way.

And we are talking about interractive psql breaking transaction because
of syntax error - almost always this is a one time typo. I'd prefere it
to be a bit more "sloopy", then deployed SQL application (e.g.
non-interactive session).
>
> 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.

Hmmm, years ago I has told, that UNIX is sloopy (does not guarantee
anything to a process: neither time to dysk when writing, nor CPU time,
nor even IRQ response time), so it will not prevail. It did. And it runs
critical systems.

As postgres is my favourite database for its ease of use (to the point
where I dont try applications which only run on its closest
free-couterpart: mysql :), there is always room for improvements (my
personal wishlist for postgres is currently 11 points long and keeping
transaction on syntax errors is even beyond that list).

-R
>