Re: Converting contrib SQL functions to new style

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Converting contrib SQL functions to new style
Дата
Msg-id 3565758.1618421782@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Converting contrib SQL functions to new style  (Mark Dilger <mark.dilger@enterprisedb.com>)
Ответы Re: Converting contrib SQL functions to new style
Список pgsql-hackers
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.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Possible typo/unclear comment in joinpath.c
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Converting contrib SQL functions to new style