On 1/14/14 10:16 AM, Pavel Stehule wrote:
2014/1/14 Florian Pflug <f...@phlo.org>
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.
At this point I'm almost tempted to agree with Florian -- I'm really
hoping we could change PL/PgSQL for the better over the next 10 years,
but given the backwards compatibility requirements we have, this seems
like an absolute nightmare. Not saying we need a version number we can
keep bumping every release, but something similar.
return back to topic
a) 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
FWIW, I would like to have this behaviour even if it's not the default
(that was my original proposal anyway). It could help catch a lot of
bugs in testing, and for important code it could be even turned on in
production (perhaps on a per-function basis). Maybe even globally, idk.
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).
While this sounds cool, running a modified postgres locally seems a lot
easier. I already have to do that for PL/PgSQL development because of
the reasons I outlined in the thread "PL/PgSQL, RAISE and error context".
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
