Re: plpgsql.consistent_into
От | Marko Tiikkaja |
---|---|
Тема | Re: plpgsql.consistent_into |
Дата | |
Msg-id | 52D516CC.6030706@joh.to обсуждение исходный текст |
Ответ на | Re: plpgsql.consistent_into (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
On 1/14/14 10:16 AM, Pavel Stehule wrote: > 2014/1/14 Florian Pflug <fgp@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
В списке pgsql-hackers по дате отправления: