Re: Converting contrib SQL functions to new style - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Converting contrib SQL functions to new style
Date
Msg-id CA+TgmobdzZc2UET6z_=e_Uia63Btb3jMX2bVSukWvE21y75o-g@mail.gmail.com
Whole thread Raw
In response to Re: Converting contrib SQL functions to new style  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Converting contrib SQL functions to new style  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Options given both on cmd-line and in the config with different values
Next
From: Tom Lane
Date:
Subject: Re: Converting contrib SQL functions to new style