Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > Just do "SET search_pa...@extschema@" at the beginning of the install > script, just like we have "SET search_path=public" there now.
Well there's the installation itself then the "runtime", as you say later... > Well, in case of functions you can always do "CREATE FUNCTION ... AS $$ > ... $$ SET search_pa...@extschema". Fair enough. > "ALTER ... SET SCHEMA" wouldn't do anything for SQL statements embedded in > plperl or plpython anyway. That's why I was thinking about adding the possibility to: - easily find your function's etc OID, that's already mainly done - be able to call/use those objects per OID Ok that sucks somehow. I think it's better than @extschema@ replacing in the extension's script parsing, though. Maybe we should just shut down this attempt at working on search_path and extensions together, again. I though it was a simple and good enough solution though, and that it would avoid the usual rat holes. But we're deep in them already. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
