Re: refactor ExecGrant_*() functions
От | Andres Freund |
---|---|
Тема | Re: refactor ExecGrant_*() functions |
Дата | |
Msg-id | 20221202172829.bicec4r4jzujan4i@awork3.anarazel.de обсуждение исходный текст |
Ответ на | refactor ExecGrant_*() functions (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: refactor ExecGrant_*() functions
|
Список | pgsql-hackers |
Hi, On 2022-12-02 08:30:55 +0100, Peter Eisentraut wrote: > From 200879e5edfc1ce93b7af3cbfafc1f618626cbe9 Mon Sep 17 00:00:00 2001 > From: Peter Eisentraut <peter@eisentraut.org> > Date: Fri, 2 Dec 2022 08:16:53 +0100 > Subject: [PATCH] Refactor ExecGrant_*() functions > > Instead of half a dozen of mostly-duplicate ExecGrant_Foo() functions, > write one common function ExecGrant_generic() that can handle most of > them. I'd name it ExecGrant_common() or such instead - ExecGrant_generic() sounds like it will handle arbitrary things, which it doesn't. And, as you mention, we could implement e.g. ExecGrant_Language() as using ExecGrant_common() + additional checks. Perhaps it'd be useful to add a callback to ExecGrant_generic() that can perform additional checks, so that e.g. ExecGrant_Language() can easily be implemented using ExecGrant_generic()? > 1 file changed, 34 insertions(+), 628 deletions(-) Very neat. It seems wrong that most (all?) ExecGrant_* functions have the foreach(cell, istmt->objects) loop. But that's a lot easier to address once the code has been deduplicated radically. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: