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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
