David E. Wheeler wrote:
> On Jun 23, 2009, at 3:02 PM, Dimitri Fontaine wrote:
>> It's "just" PostgreSQL reading an SQL file (foo.install.sql) and
>> parsing each statement etc, so we obviously have the machinery to
>> recognize SQL objects names and schema qualification. Replacing the
>> schema on-the-fly should be a SMOP? (*cough*)
>
> Well, no. I might have written a function in PL/Perl. Is PostgreSQL
> going to parse my Perl function for unqualified function calls? Really?
> Hell, I don't think that PL/pgSQL is parsed until functions are loaded,
> either, though I may be wrong about that.
>
> Better is to have some magic so that functions in an extension magically
> have their schema put onto the front of search_path when they're called.
> Or when they're compiled. Or something.
With the given example of extension "foo" depending on "bar" and "baz",
I'd suggest:
- Default search_path = ext:self, pg_catalog
- ext:self = <wherever foo installs>
- ext:bar = <wherever bar installs>
- ext:baz = <wherever baz installs>
You *can't* have anything other than the current package in the
search-path in case bar/baz have conflicting objects.
I've no idea if ext:<name> makes sense from a parser point of view, but
the idea is to map extension name to a schema. If possible, this should
work anywhere in PG that a schema can be specified.
So - If extension foo is installed in schema1 then ext:foo.fn1() is the
same as schema1.fn1()
-- Richard Huxton Archonet Ltd