Re: ALTER TABLE OWNER: change indexes

OK, the issue with this patch is that it fixes ownership of INDEXES.
The complaint is that we shouldn't have ownership of indexes.  However,
we are clearly now preventing anyone except the table owner from
creating indexes, so it seems there is ownership, or at least a
restriction.


Now, we are we going with this?  Can we just remove ownership of indexes
totally?  And sequences?  Is that the direction we want to go in?  I
can't imagine it is very hard to do.  Or is the problem that we should
not be reporting the owner of these items?


---------------------------------------------------------------------------

Neil Conway wrote:
> On Mon, 2002-02-25 at 18:48, Tom Lane wrote:
> > Neil Conway <nconway@klamath.dyndns.org> writes:
> > > Additionally, if someone eventually fixes the index-ownership situation,
> > > the changes to command.c to remove the index recursion are trivial.
> >
> > ... but won't necessarily get done.  More to the point, they may confuse
> > someone who's trying to refactor the code: without careful thought, he
> > might think he needs to support recursion over indexes as well as child
> > tables.
>
> Not if the code includes a comment (as it does) that the recursion is
> intended _only_ to support changing the ownership of any indexes which
> belong to the table.
>
> IMHO, it's not confusing at all: in the current code, indexes have
> owners, and should be owned by the owner of the table they belong to.
> The patch makes this consistent; without the patch, one might conclude
> that there are reasonable situations in the owner of a table should not
> own its indexes, which is incorrect AFAIK.
>
> BTW, should ownership be removed from sequences as well?
>
> > > This patch also includes some refactoring and code cleanups that are
> > > useful in any case.
> >
> > Sure.  Please resubmit just that part.
>
> Okay, I've attached a patch which implements this.
>
> I think it is still a bad idea to leave code that is _known_ to be
> broken in the tree, waiting for a possible future enhancement that no
> one has committed to writing. But it's your call -- please apply either
> this patch, or the previous one (-3) as you see fit.
>
> Cheers,
>
> Neil
>
> --
> Neil Conway <neilconway@rogers.com>
> PGP Key ID: DB3C29FC

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026