On 09/03/2014 03:14 AM, Joel Jacobson wrote:
I'm in favour of Tom's idea. To merely make the plpgsql2 "language" a
way of explicitly saying you want
a specific exact combination of features/beaviour/settings which we
can implemented in plpgsql's existing codebase.
Since it was about 100 posts since Tom's post, maybe it's worth
repeating for those who missed it:
What I would think about is
c) plpgsql and plpgsql2 are the same code base, with a small number
of places that act differently depending on the language version.
We could alternatively get the result by inventing a bunch of pragma
declarations, or some similar notation, that control the behavioral
changes one-at-a-time. That might even be worth doing anyway, in
case somebody likes some of the ideas and others not so much. But
I'd see the language version as a convenient shorthand for enabling a
specified collection of pretty-localized incompatible behavior changes.
If they're not pretty localized, there's going to be a barrier to
uptake, very comparable to the python3 analogy mentioned upthread.
regards, tom lane
I fully agree on this approach. It's maintainable and it will be
useful from day 1.
One can take that approach to another, more generic level. Like GUCs can
be set on a ROLE base with ALTER USER or ALTER ROLE, PL specific GUCs
could be set via "ALTER LANGUAGE foo SET ...".
The possibility to CREATE LANGUAGE mybetterpl, pointing to the same PL
handler function, exists already. And the same mechanism could be used
by other languages, like PL/Python (for whatever such language might
need such settings).
This way an application can define the language settings, it needs, by
simply creating its own language, based on all the possible permutations
of those PRAGMA/GUC settings.
Regards,
Jan
--
Jan Wieck
Senior Software Engineer
http://slony.info
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
