Re: search_path vs extensions

Le 29 mai 09 à 17:12, Tom Lane a écrit :
> What it sounds like to me is an amazingly complicated gadget with
> absolutely no precedent of successful use anywhere. We'll spend a
> year
> fooling with the details of this and be no closer to actually solving
> the problem at hand, namely getting a simple workable extension
> packaging facility.

What it sounds like to me is a way to all agree what the finished
feature would look like, allowing us to commit incremental patches.
Coarse(?) grained plan:

A. nested namespaces

B. packaging facility, each module have its own schema in pg_extension
sub schemas in pg_extension.myext are possible and welcomed to
organize things

C. synonyms, allowing DBA to organise the visibility as they see fit,
and to overcome search_path limitations

The ordering of those points would still need to be talked about, I'd
see A as necessary to get through before B implementation begins, but
at least this would solve the search_path and "default" schema
destination points while designing the extension packaging facility.
Then when B is done, or parallel to development of B, we can have C,
so that everyone is happy: it works and is not a PITA to maintain.

All in all, agreeing about those steps now would open up the "real"
matters of extension packaging to begin.

Regards,
--
dim

PS: I realize that my line of thoughts is tied to imagining that the
more visible (and complex, as in agreeing on bikesched color) part of
the packaging facility user design is its relationship with schemas
and search_path. Even the SQL syntax of creating (altering/droping/
granting) the new SQL object seems like it'll be easier.
That done, the rest of it is mainly self-constrained, I don't foresee
another such controversial part related to the existing system...

Now, that's in the archive and I'll soon really look like a fool :)