On Sun, Oct 31, 2010 at 12:45 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Bernd Helmle <maili...@oopsware.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
