Re: search_path vs extensions - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: search_path vs extensions
Date
Msg-id 4A202117.9080900@agliodbs.com
Whole thread Raw
In response to Re: search_path vs extensions  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Dimitri,

> We'd still need search_path in there, as Python's still using a path.
> With 'default' search_path you'd have to qualify your type as
> pg_extensions.postgis.submodule.special_type, with pg_extensions in
> search_path the following notation would find it too:
> postgis.submodule.special_type.
> And if you have pg_extensions.postgis.submodule in the search_path, then
> you can use special_type without having to (nest-) schema qualify it.

But *incompatible* with SQL truncation of qualified names.  Remember 
that you can refer to something by any portion of its qualified name, 
such as:

pg_extensions.postgis.submodule.special_type
postgis.submodule.special_type
submodule.special_type
special_type

... are all valid.  Which is fine until you think that we could have a:

pg_extensions.pg_tap.submodule.special_type

or even a:

schema submodule.special_type

which would confuse both the search path and the user.  What this means 
is that all schema names would have to be unique, whether they are 
nested or not.  Which makes subschema *within* an extension rather useless.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: explain analyze rows=%.0f
Next
From: Konstantin Izmailov
Date:
Subject: Re: information_schema.columns changes needed for OLEDB