Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"
Date: 2020-07-11 06:00:32
Message-ID: 20200711060032.GA21680@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-07-11 06:05:33 Re: pg_regress cleans up tablespace twice.
Previous Message Pavel Stehule 2020-07-11 05:38:21 Re: calling procedures is slow and consumes extra much memory against calling function