Re: ALTER TABLE OWNER: change indexes - Mailing list pgsql-patches

From Tom Lane
Subject Re: ALTER TABLE OWNER: change indexes
Date
Msg-id 14904.1014608262@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER TABLE OWNER: change indexes  (Neil Conway <nconway@klamath.dyndns.org>)
Responses Re: ALTER TABLE OWNER: change indexes  (Neil Conway <nconway@klamath.dyndns.org>)
List pgsql-patches
Neil Conway <nconway@klamath.dyndns.org> writes:
> You mentioned child-tables: should ALTER TABLE OWNER also recurse for
> those?

Only if you want to put in an "ONLY" variant to suppress the recursion.
(This might actually be a reasonable thing to do, if so.  But I don't
have a strong feeling about it.)

> BTW, a question on coding style: are large source files discouraged?

Personally I prefer source file == logical module, however big that is.
For stuff like this it's not always clear where the module boundaries
should be drawn, of course.  I really hate the style where each C
function lives in a separate source file; beyond that it's all a matter
of taste to some extent.

My thought would be to group all the ALTER TABLE variants into one file,
perhaps "alter.c", separate from the other current inhabitants of
command.c.  Note that alter.c could be a lot smaller than the current
sum of the ALTER routine sizes, given appropriate refactoring to
eliminate duplicate code.

>> 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...

I seem to recall discussing this with Gavin Sherry or Christopher
Kings-Lynne sometime in the past six months or so, but can't find the
thread at the moment.  AFAIR it hadn't really progressed beyond the
observation that there was an awful lot of duplicated code in those
routines, and that the ones that weren't duplicating it were a few
bricks shy of a load (eg, didn't support recursion but should).
So we were wondering about ways to consolidate the duplication into
some sort of common control routine.


>> 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 ;-)

Well, see Peter's suggestion that this is all wrong because indexes
don't have meaningful ownership anyway.  I think he's got a point...

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Updated TODO item
Next
From: Bruce Momjian
Date:
Subject: Re: Patch to add CREATE OPERATOR CLASS