Re: ALTER OBJECT any_name SET SCHEMA name

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, 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-10-31 18:42:53
Message-ID: AANLkTinEgA7wrJt2FPUpTsr3DqgwHCDQHKTKfjbmzbdv@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 31, 2010 at 12:45 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Bernd Helmle <mailings(at)oopsware(dot)de> writes:
>> This reminds me of a small discussion we had some years ago when i targeted
>> this for the sake of completeness of ASS (see
>> <http://archives.postgresql.org/pgsql-patches/2006-06/msg00021.php>).
>
> Discovered it, thanks for the pointer.
>
>> I didn't follow the previous discussions about EXTENSION very closely, but
>> to amend the idea made in the mentioned thread, couldn't we just invent a
>> facility to move classes of objects belonging to an extension, only?
>
> Well under the hood you still need about the same code. In the current
> patch version I have, that would mean forgetting about a ~20 lines long
> function and keeping the other two, 10+30 lines about.
>
> Now if someone has a idea on how to have a single routine that knows how
> to deal with any object type and change its namespace, I'm all ears, and
> willing to have a try at it. Coding in C is for me a twice a year
> exercise, so whatever I come up with will be... improvable, I fear.

I guess it's a question of how much special case code there is. The
new objectaddress.c code knows how to deal with lots of different
object types, but for example in the case of ALTER TABLE .. SET
SCHEMA, what's there now is enmeshed in a complex structure so as to
allow multiple ALTER TABLE subcommands in a single statement, and it
has further special-case logic to handle moving the rowtype and
related indexes, sequences, and constraints. It seems hard to fit
that into a general framework, but maybe it could be done for other
object types.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-10-31 18:43:07 Re: type info refactoring
Previous Message Robert Haas 2010-10-31 18:30:33 Re: type info refactoring