Re: refactor ExecGrant_*() functions - Mailing list pgsql-hackers

From Andres Freund
Subject Re: refactor ExecGrant_*() functions
Date
Msg-id 20221202172829.bicec4r4jzujan4i@awork3.anarazel.de
Whole thread Raw
In response to refactor ExecGrant_*() functions  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: refactor ExecGrant_*() functions  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_dump: Remove "blob" terminology
Next
From: Tom Lane
Date:
Subject: Bogus rte->relkind for EXCLUDED pseudo-relation