Re: Handling changes to default type transformations in PLs

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Handling changes to default type transformations in PLs
Дата
Msg-id CAFj8pRB1mcezdLm24bdOfMOLv=qGw42YKk7FwE18cGaRUwgVkA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Handling changes to default type transformations in PLs  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Handling changes to default type transformations in PLs