Re: restructuring "alter table" privilege checks - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: restructuring "alter table" privilege checks
Date
Msg-id 4B5BC135.8060903@kaigai.gr.jp
Whole thread Raw
In response to Re: restructuring "alter table" privilege checks  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: restructuring "alter table" privilege checks  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
List pgsql-hackers
(2010/01/24 12:16), Robert Haas wrote:
> On Sat, Jan 23, 2010 at 10:11 PM, KaiGai Kohei<kaigai@kaigai.gr.jp>  wrote:
>> If we put the new ATSimplePermissions() with all the needed information
>> just after gathering them at the execution stage, we don't need to have
>> some of exceptions which takes additional checks except for ownership
>> on the relation to be altered.
>
> Maybe I'm still not understanding, but I don't see how you're going to
> do this without a massive pile of spaghetti code and a function with
> about 12 parameters.  Feel free to show some code, but I think this is
> a non-starter.

Hhmmm,...

Indeed, indeed, if a single function tries to handle all the ALTER TABLE
options, it needs many function arguments, because ALTER TABLE is one of
the most functional statement in PostgreSQL...

If the basis is head of the execution phase, it does not need a big switch
... case branch in ATSimplePermissions, because it is already branched in
ATExecCmd(). However, it also has tradeoff that we have multiple minor version
of functions to check ALTER TABLE permissions.

Perhaps, it may be a good idea to make two conceptual patches both head of
the ATPrepCmd() and ATExec*(). They will make clear good/bad points between
two approaches.

Is it waste of efforts?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Next
From: KaiGai Kohei
Date:
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns