Re: search_path vs extensions

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: search_path vs extensions
Дата
Msg-id 4A202117.9080900@agliodbs.com
обсуждение исходный текст
Ответ на Re: search_path vs extensions  (Dimitri Fontaine <dfontaine@hi-media.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: explain analyze rows=%.0f
Следующее
От: Konstantin Izmailov
Дата:
Сообщение: Re: information_schema.columns changes needed for OLEDB