Re: Handling changes to default type transformations in PLs - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Handling changes to default type transformations in PLs
Date
Msg-id CAFj8pRB1mcezdLm24bdOfMOLv=qGw42YKk7FwE18cGaRUwgVkA@mail.gmail.com
Whole thread Raw
In response to Re: Handling changes to default type transformations in PLs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers




> 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

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Next
From: Pavel Stehule
Date:
Subject: Re: Handling changes to default type transformations in PLs