On Wed, Dec 20, 2017 at 5:43 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Peter Eisentraut wrote:
>> 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:
>
>> > 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.
>
> That's correct, and using a single implementation as in the posted patch
> is desirable. I was not happy about having to add
> EventTriggerSupportsGrantObjectType (c.f. commit 296f3a605384).
Hm. OK. I would have thought that allowing a new object to work
automatically is actually we would have liked to avoid for safety. So
complain withdrawn.
-stringify_adefprivs_objtype(GrantObjectType objtype)
+stringify_adefprivs_objtype(ObjectType objtype)
[...]
+ default:
+ elog(ERROR, "unrecognized grant object type: %d", (int) objtype);
+ return "???"; /* keep compiler quiet */
}
-
- elog(ERROR, "unrecognized grant object type: %d", (int) objtype);
- return "???"; /* keep compiler quiet */
Still this portion in 0001 is something that we try to avoid as much
as possible, no? I would have thought that all object types should be
listed directly so as nothing is missed in the future.
--
Michael