Re: pg_execute_from_file review
От | Dimitri Fontaine |
---|---|
Тема | Re: pg_execute_from_file review |
Дата | |
Msg-id | 87r5ds1v4q.fsf@hi-media-techno.com обсуждение исходный текст |
Ответ на | Re: pg_execute_from_file review (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > Er ... what good is that? A non-relocatable extension doesn't *need* > any such substitution, because it knows perfectly well what schema it's > putting its stuff into. Only the relocatable case has use for it. So > you might as well drop the substitution mechanism entirely. Funnily enough, I see it the exact opposite way. relocatable is true A relocatable extension installs all its object into the first schema of the search_path. As an extension's script author,you have to make sure you're not schema qualifying any object that you create. Note that contrib/ is working this way but forcing the search_path first entry into being "public". relocatable is false An extension that needs to know where some of its objects are installed is not relocatable. As the user won't be ableto change the schema where the extensions gets installed, he's given the possibility to specify the schema at installationtime. The extension installation script is then required to use the @extschema@ placeholer as the schemato work with. That will typically mean the script's first line is: SET search_path TO @extschema@; Then you can also CREATE FUNCTION … SET search_path TO @extschema@ for security reasons. With that support in, the CREATE EXTENSION foo WITH SCHEMA bar could simply run the ALTER EXTENSION foo SET SCHEMA bar internally, so that's not a burden for the user. So that simple things are simple both for the extension's author and the users, but complex things still possible and supported here. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: