On Sat, Jan 23, 2010 at 8:33 PM, KaiGai Kohei wrote:
> (2010/01/24 9:08), Robert Haas wrote:
>>
>> On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Kohei wrote:
>>>
>>> However, it is unclear for me whether the revised ATSimplePermissions()
>>> provide cleaner code than currently we have, because it also
(2010/01/24 9:08), Robert Haas wrote:
On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Kohei wrote:
However, it is unclear for me whether the revised ATSimplePermissions()
provide cleaner code than currently we have, because it also needs
a big switch ... case statement within.
Am I misunderstanding so
On Sat, Jan 23, 2010 at 2:17 AM, KaiGai Kohei wrote:
> However, it is unclear for me whether the revised ATSimplePermissions()
> provide cleaner code than currently we have, because it also needs
> a big switch ... case statement within.
>
> Am I misunderstanding something?
Well, not everyone is
(2010/01/23 1:27), Robert Haas wrote:
So, what if we treat these two cases separately? The part-B checks -
on the other operations involved in ALTER TABLE - are by definition
idiosyncratic. What type of object we're checking and what permission
we're checking for is inextricably bound up with w
Robert Haas writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't particularly like this patch, mainly because I disagree with
randomly removing permissions checks without any sort of plan about
where they ought to go.
> [ a plan for rearranging ALTER TABLE's checks ]
Works fo
On Thu, Dec 17, 2009 at 10:09 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> KaiGai Kohei writes:
>> > [ patch to remove EnableDisableRule's permissions check ]
>>
>> I don't particularly like this patch, mainly because I disagree with
>> randomly removing permissions checks
