Re: plpgsql.consistent_into - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: plpgsql.consistent_into |
| Date | |
| Msg-id | CAFj8pRAmjTB7NxTrguVfCniX=nsGKr16gEHOn7WMVBSnQeVwAw@mail.gmail.com Whole thread Raw |
| In response to | Re: plpgsql.consistent_into (Florian Pflug <fgp@phlo.org>) |
| Responses |
Re: plpgsql.consistent_into
|
| List | pgsql-hackers |
2014/1/14 Florian Pflug <fgp@phlo.org>
On Jan14, 2014, at 00:52 , Marko Tiikkaja <marko@joh.to> wrote:The question is, how many bugs stemmed from wrong SQL queries, and what
> 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.
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.Which doesn't help, because the GUC isn't tied to the code. This *adds*
> Yes, it breaks backwards compatibility, but that's why there's a nice GUC.
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.I very strongly believe that languages don't get better by adding a thousand
> 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".
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 dislike this proposal
too enterprise, too complex, too bad - after ten years we can have a ten language versions and it helps nothing.
return back to topica) there is agreement so we like this functionality as plpgsql option
b) there is no agreement so we would to see this functionality as default (or in near future)
@b is a topic, that we should not to solve and it is back again and again. Sometimes we have success, sometimes not. Temporal GUC is not enough solution for some people.
So my result - @a can be implement, @b not
and we can continue in other thread about SELECT INTO redesign and about possibilities that we have or have not. It is about personal perspective - someone can thinking about missing check after INTO as about feature, other one can see it as bug. My opinion - it is a bug with possible ambiguous result and possible negative performance impacts. Probably we can precise a doc about wrong and good usage SELECT INTO clause.
and we can continue in other thread about SELECT INTO redesign and about possibilities that we have or have not. It is about personal perspective - someone can thinking about missing check after INTO as about feature, other one can see it as bug. My opinion - it is a bug with possible ambiguous result and possible negative performance impacts. Probably we can precise a doc about wrong and good usage SELECT INTO clause.
I am working on plpgsql_debug extension and I am thinking so I am able (with small change in plpgsql executor) implement this check as extension. So it can be available for advanced users (that will has a knowledge about additional plpgsql extensions).
Regards
Pavel
regards
Pavel
Pavel
best regards,
Florian Pflug
pgsql-hackers by date: