Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind" - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"
Date
Msg-id 20200711060032.GA21680@paquier.xyz
Whole thread Raw
In response to Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"
List pgsql-hackers
On Wed, Jul 01, 2020 at 05:04:19PM -0700, Mark Dilger wrote:
> Most of the work in this patch is mechanical replacement of if/else
> if/else statements which hinge on relkind to switch statements on
> relkind.  The patch is not philosophically very interesting, but it
> is fairly long.  Reviewers might start by scrolling down the patch
> to the changes in src/include/catalog/pg_class.h
>
> There are no intentional behavioral changes in this patch.

Please note that 0002 does not apply anymore, there are conflicts in
heap.c and tablecmds.c, and that there are noise diffs, likely because
you ran pgindent and included places unrelated to this patch.  Anyway,
I am not really a fan of this patch.  I could see a benefit in
switching to an enum so as for places where we use a switch/case
without a default we would be warned if a new relkind gets added or if
a value is not covered, but then we should not really need
RELKIND_NULL, no?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: calling procedures is slow and consumes extra much memory against calling function
Next
From: Michael Paquier
Date:
Subject: Re: pg_regress cleans up tablespace twice.