> On Apr 13, 2021, at 3:26 PM, Tom Lane <t...@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. The problem
seems to be that we can't syntactically refer to the schema of an extension.
We have to instead query pg_catalog.pg_extension joined against
pg_catalog.pg_namespace and then interpolate the namespace name into strings
that get executed, which is ugly.
This syntax is perhaps a non-starter, but conceptually something like:
-CREATE DOMAIN earth AS cube
+CREATE DOMAIN earthdistance::->earth AS cube::->cube
Then we'd perhaps extend RangeVar with an extensionname field and have either a
schemaname or an extensionname be looked up in places where we currently lookup
schemas, adding a catcache for extensions. (Like I said, probably not worth
doing.)
We could get something like this working just inside the CREATE EXTENSION
command if we expanded on the @extschema@ idea a 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
or such, with @@foo@@ being parsed out, looked up in pg_extension join
pg_namespace, and substituted back in.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
