Re: Converting contrib SQL functions to new style
От | Mark Dilger |
---|---|
Тема | Re: Converting contrib SQL functions to new style |
Дата | |
Msg-id | EEB14707-5E36-4CB1-A5ED-B8082E1FB014@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Converting contrib SQL functions to new style (Vik Fearing <vik@postgresfriends.org>) |
Ответы |
Re: Converting contrib SQL functions to new style
|
Список | pgsql-hackers |
> On Apr 14, 2021, at 2:47 PM, Vik Fearing <vik@postgresfriends.org> wrote: > > On 4/14/21 7:36 PM, Tom Lane wrote: >> Mark Dilger <mark.dilger@enterprisedb.com> writes: >>>> On Apr 13, 2021, at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> However I think we may still need an assumption that earthdistance >>>> and cube are in the same schema --- any comments on that? >> >>> This is probably not worth doing, and we are already past feature >>> freeze, but adding syntax to look up the namespace of an extension might >>> help. >> >> Yeah, that idea was discussed before (perhaps only in private >> security-team threads, though). We didn't do anything about it because >> at the time there didn't seem to be pressing need, but in the context >> of SQL function bodies there's an obvious use-case. >> >>> We could get something like this working just inside the CREATE EXTENSION command if we expanded on the @extschema@ ideaa bit. At first I thought this idea would suffer race conditions with concurrent modifications of pg_extension or pg_namespace,but it looks like we already have a snapshot when processing the script file, so: >> >>> -CREATE DOMAIN earth AS cube >>> +CREATE DOMAIN @@earthdistance@@::earth AS @@cube@@::cube >> >> Right, extending the @extschema@ mechanism is what was discussed, >> though I think I'd lean towards something like @extschema:cube@ >> to denote the schema of a referenced extension "cube". >> >> I'm not sure this is useful enough to break feature freeze for, >> but I'm +1 for investigating it for v15. > Just like we have a pseudo "$user" schema, could we have a pseudo > "$extension" catalog? That should avoid changing grammar rules too much. > > CREATE TABLE unaccented_words ( > word "$extension".citext.citext, > CHECK (word = "$extension".unaccent.unaccent(word) > ); Having a single variable $extension might help in many cases, but I don't see how to use it to handle the remaining cross-extensionreferences, such as earthdistance needing to reference cube. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: