"David E. Wheeler" <da...@kineticode.com> writes:
> The other question I have, though, is how important is it to have extensions
> live in a particular schema since there seems to be no advantage to doing so.
> With the current patch, I can put extension "foo" in schema "bar", but I
> can't put any other extension named "foo" in any other schema. It's in schema
> "bar" but is at the same time global. That doesn't make much sense to me.
There's a difference between whether an extension as such is considered
to belong to a schema and whether its contained objects do. We can't
really avoid the fact that functions, operators, etc must be assigned to
some particular schema. It seems not particularly important that
extension names be schema-qualified, though --- the use-case for having
two different extensions named "foo" installed simultaneously seems
pretty darn small. On the other hand, if we were enforcing that all
objects contained in an extension belong to the same schema, it'd make
logistical sense to consider that the extension itself belongs to that
schema as well. But last I heard we didn't want to enforce such a
restriction.
I believe what the search_path substitution is actually about is to
provide a convenient shorthand for the case that all the contained
objects do indeed live in one schema, and you'd like to be able to
select that schema at CREATE EXTENSION time. Which seems like a useful
feature for a common case. We've certainly heard multiple complaints
about the fact that you can't do that easily now.
BTW, I did think of a case where substitution solves a problem we don't
presently have any other solution for: referring to the target schema
within the definition of a contained object. As an example, you might
wish to attach "SET search_path = @target_schema@" to the definition of
a SQL function in an extension, to prevent search-path-related security
issues in the use of the function. Without substitution you'll be
reduced to hard-wiring the name of the target schema.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
