Re: commands subdirectory continued -code cleanup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: commands subdirectory continued -code cleanup
Date
Msg-id 2992.1019244852@sss.pgh.pa.us
Whole thread Raw
In response to commands subdirectory continued -code cleanup  (John Gray <jgray@azuli.co.uk>)
Responses Re: commands subdirectory continued -code cleanup  (John Gray <jgray@azuli.co.uk>)
List pgsql-hackers
John Gray <jgray@azuli.co.uk> writes:
> Sequences still seem to work after they've had attributes renamed, but I
> see little value in being able to do this. Is it OK to prohibit the
> renaming of sequence columns?

That seems like an error to me.  Setting defaults, constraints, etc on a
sequence is bogus too --- do we catch those?

> There are also permissions checks made in tcop/utility.c before
> AlterTableOwner and renamerel are called. It may be best to move these
> into commands/tablecmds.c. It seems that tcop/utility.c was supposed to
> handle the permissions checks for statements, but the inheritance
> support has pushed some of that into commands/ . Should permissions
> checking for other utility statements be migrated to commands/ for
> consistency? I don't propose to do this now -but it might be a later
> stage in the process.

Not sure.  There are subroutines in utility.c that are useful for
this purpose, and I don't really see the value of having them called
from all over the place when it can be more localized.  We should
probably be consistent about having tablecmds.c make all the relevant
permissions checks for its operations, but I don't think that
necessarily translates into the same choice for the rest of commands/.
AFAIR none of the rest of commands/ has the recursive-operations issue
that forces this approach for table commands.
        regards, tom lane


pgsql-hackers by date:

Previous
From: John Gray
Date:
Subject: commands subdirectory continued -code cleanup
Next
From: Fernando Nasser
Date:
Subject: Re: commands subdirectory continued -code cleanup