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. > Yes, it breaks backwards compatibility, but that's why there's a nice GUC. Which doesn't help, because the GUC isn't tied to the code. This *adds* an error case, not remove one - now, instead of getting your code correct, you *also* have to get the GUC correct. If you even *know* that such a GUC exists. > 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. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
