Skip site navigation (1) Skip section navigation (2)

Re: ALTER OBJECT any_name SET SCHEMA name

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER OBJECT any_name SET SCHEMA name
Date: 2010-11-02 13:03:44
Message-ID: m262wf6fnz.fsf@2ndQuadrant.fr (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> How about something like:
>
> CREATE EXTENSION myextension ... SCHEMA myschema;
>
> And in the .sql file in the extension you could have special markers for the
> schema, something like:
>
> CREATE FUNCTION otherfunction() AS ...;
> CREATE FUNCTION foo() AS $$ SELECT 'foo', @extschema(at)(dot)otherfunction() $$;
>
> @extschema@ would be search&replaced at CREATE EXTENSION time with the
> schema specified by the user.

Please find attached v12 of the patch, which implements that idea.

And a new pg_execute_from_file patch version too: the function now has a
second (documented) variant accepting a VARIADIC text[] argument where
to put pairs of name and value for the placeholders in the script.

I guess it would be cleaner with hstore in core, but we're not there
yet, so meanwhile it's a variable length array.

The CREATE EXTENSION ... WITH SCHEMA ... command will then use the
variadic form of pg_execute_from_file() with a single variable in there,
the proposed @extschema(at)(dot) When the option is not used, the placeholder
is still set, hard-coded to 'public'.

Contrib scripts have been all changed this way:

- SET search_path = public;
+ SET search_path = @extschema@;

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


Attachment: pg_execute_from_file.v4.patch
Description: text/x-patch (9.9 KB)
Attachment: extension.v12.patch.gz
Description: application/octet-stream (47.3 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-11-02 13:38:27
Subject: Re: timestamp of the last replayed transaction
Previous:From: Fujii MasaoDate: 2010-11-02 11:38:28
Subject: timestamp of the last replayed transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2013 The PostgreSQL Global Development Group