Re: refactor ExecGrant_*() functions

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: refactor ExecGrant_*() functions
Date: 2022-12-02 17:28:29
Message-ID: 20221202172829.bicec4r4jzujan4i@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)eisentraut(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-12-02 17:34:36 Bogus rte->relkind for EXCLUDED pseudo-relation
Previous Message Andrew Dunstan 2022-12-02 17:26:29 Re: pg_dump: Remove "blob" terminology