> > 3) Add the concept of PL API versions. This would allow users to specify > > So that leaves #3, which doesn't seem all that unreasonable from here. > We don't have a problem with bundling a bunch of unrelated changes > into any one major PG revision. The scripting languages we're talking > about calling do similar things. So why not for the semantics of the > glue layer? > > It seems like you really need to be able to specify this at the > per-function level, which makes me think that specifying > "LANGUAGE plpython_2" or "LANGUAGE plperl_3" might be the right > kind of API. >
I am not big fan of this proposal. A users usually would to choose only some preferred features - and this design has maybe too small granularity. Objections: * usually is used keyword REVISON - so syntax can be LANGUAGE plpython REVISION 3. It is more readable. You need to specify preferred revision for any language. The revision is persistent. The behave is same like Tom's proposal, but I hope so this can be better readable and understandable regards Pavel > > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
