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

From Mark Dilger
Subject Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"
Date
Msg-id 5CA53A5E-5070-432D-987C-E6AB52E2A411@enterprisedb.com
Whole thread Raw
In response to 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"  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers

> On Jun 3, 2020, at 10:05 AM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
>  I have another patch (to be posted shortly) that cleans up the #define RELKIND_XXX stuff using a new RelKind enum
andspecial macros while keeping the relkind fields as type 'char'.  Along with converting code to use switch(relkind)
ratherthan if (relkind...) statements, the compiler now warns on unhandled cases when you add a new RelKind to the
list,making it easier to find all the places you need to update.  I decided to keep that work independent of this
patch,as the code is logically distinct. 

Most of the work in this patch is mechanical replacement of if/else if/else statements which hinge on relkind to switch
statementson relkind.  The patch is not philosophically very interesting, but it is fairly long.  Reviewers might start
byscrolling down the patch to the changes in src/include/catalog/pg_class.h 

There are no intentional behavioral changes in this patch.


—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company




Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SQL-standard function body
Next
From: michael@paquier.xyz
Date:
Subject: Re: min_safe_lsn column in pg_replication_slots view