On Sun, 2002-02-24 at 17:43, Tom Lane wrote:
> It'd probably be best to redesign the ALTER TABLE routines so that
> the recursive execution routine accepts a relation OID rather than a
> relation name, with a front-end routine that does a one-time name-to-
> OID lookup. Recursion using OID will be simpler than recursion using
> name, for both child-table and index cases. And it won't break for
> schemas.
You mentioned child-tables: should ALTER TABLE OWNER also recurse for
those?
BTW, a question on coding style: are large source files discouraged? I
usually like to separate my source into relatively small files, but
there are a bunch of files in the tree with 2000, 3000 or more lines of
code. Is this the preferred style, or would smaller files (divided in
logical groupings of functions, of course) be better?
> Perhaps this could be done as part of the overall refactoring of the
> ALTER code that someone (I forget who) was going to look at doing.
Do you have any more information on this? (e.g. an ML thread) I could
pick up this work if it's been dropped...
> Another point that maybe does need immediate attention: as coded,
> reassignment of ownership of a table won't affect the associated
> TOAST table, if any. Should it?
Dunno, I don't know anything about TOAST. I would think if anyone would
know, it'd be you ;-)
The revised patch is attached. It follows Tom's suggestion and does
recursion using the OID of the relation (and the sysid of the user, as
well). Since this involved basically rewriting ALTER TABLE OWNER, I may
have messed something up -- but it works, AFAICT.
Now that I've changed ALTER TABLE OWNER to use recursion-with-oid,
should I make changes to the other ALTER TABLE functions as necessary?
Comments and criticism are welcome.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC