Re: Extensions User Design

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