On 1/13/14, 6:16 PM, Florian Pflug wrote:
On Jan14, 2014, at 00:52 , Marko Tiikkaja <ma...@joh.to> wrote:
When I've worked with PL/PgSQL, this has been a source of a few bugs that
would have been noticed during testing if the behaviour of INTO wasn't as
dangerous as it is right now.
The question is, how many bugs stemmed from wrong SQL queries, and what
percentage of those would have been caught by this? The way I see it, there
are thousands of ways to screw up a query, and having it return multiple
rows instead of one is just one of them.
A query that's simply wrong is more likely to fail consistently. Non-strict use
of INTO is going to fail in very subtle ways (unless you actually DO want just
the first row, in which case you should explicitly use LIMIT 1).
If we're not going to scrap PL/PgSQL and
start over again, we are going to have to do changes like this to make the
language better. Also I think that out of all the things we could do to
break backwards compatibility, this is closer to "harmless" than "a pain
in the butt".
I very strongly believe that languages don't get better by adding a thousand
little knobs which subtly change semantics. Look at the mess that is PHP -
we absolutely, certainly don't want to go there. The most important rule in
language design is in my opinion "stick with your choices". C, C++ and JAVA
all seem to follow this, and it's one of the reasons these languages are
popular for big projects, I think.
The way I see it, the only OK way to change existing behaviour is to have
the concept of a "language version", and force code to indicate the language
version it expects. The important thing is that the language version is an
attribute of code, not some global setting that you can change without ever
looking at the code it'd affect.
So if we really want to change this, I think we need to have a
LANGUAGE_VERSION attribute on functions. Each time a major postgres release
changes the behaviour of one of the procedural languages, we'd increment
that language's version, and enable the old behaviour for all functions
tagged with an older one.
I like that idea. It allows us to fix past decisions that were ill considered
without hosing all existing code.
BTW, have we always had support for STRICT, or was it added at some point? It's
in 8.4, but I don't know how far back it goes.
And if we've always had it, why on earth didn't we make STRICT the default
behavior?
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
