Re: Converting contrib SQL functions to new style

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Converting contrib SQL functions to new style
Дата
Msg-id CA+TgmobdzZc2UET6z_=e_Uia63Btb3jMX2bVSukWvE21y75o-g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Converting contrib SQL functions to new style  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Converting contrib SQL functions to new style
Список pgsql-hackers
On Wed, Apr 14, 2021 at 1:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Doesn't help that much, because you still have to reference objects
> already created by your own extension, so it's hard to see how the
> target schema won't need to be in the path.

Oh, woops.

> Could we hack things so that extension scripts are only allowed to
> reference objects created (a) by the system, (b) earlier in the
> same script, or (c) owned by one of the declared prerequisite
> extensions?  Seems like that might provide a pretty bulletproof
> defense against trojan-horse objects, though I'm not sure how much
> of a pain it'd be to implement.

That doesn't seem like a crazy idea, but the previous idea of having
some magic syntax that means "the schema where extension FOO is" seems
like it might be easier to implement and more generally useful. If we
taught the core system that %!!**&^%?(earthdistance) means "the schema
where the earthdistance is located" that syntax might get some use
even outside of extension creation scripts, which seems like it could
be a good thing, just because code that is used more widely is more
likely to have been debugged to the point where it actually works.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Options given both on cmd-line and in the config with different values
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Converting contrib SQL functions to new style