On 12/15/17 17:34, Michael Paquier wrote:
> On Sat, Dec 16, 2017 at 2:39 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> On 12/13/17 02:35, Michael Paquier wrote:
>>> Patch 0001 is simply removing EventTriggerSupportsGrantObjectType(),
>>> but shouldn't we keep it and return an error for objects that have no
>>> GRANT support? Returning conditionally true looks like a trap waiting
>>> to take someone in.
>>
>> I don't understand the motivation for this. It would just be two lists
>> for the same thing.
>
> Not really. What grant supports is a subset of what event triggers do.
>
>> I think the potential for omission would be much greater that way.
>
> That's the whole point of not having "default" in the switches, no?
> Any object additions would be caught at compilation time.
I think the purpose of EventTriggerSupportsGrantObjectType() is to tell
which object types are supported for event triggers. The purpose is not
to tell which object types are supported by GRANT.
The way I have written it, if GRANT gets support for a new object type,
then event trigger support automatically happens, without having to
update another list.
As a related example, we use the generic
EventTriggerSupportsObjectType() for RenameStmt, even though we don't
actually support RenameStmt on every ObjectType. And there are probably
more examples like that. Taken to the extreme, you'd need to remove
EventTriggerSupportsObjectType() altogether.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
