future-proofing relkind tests, take two - Mailing list pgsql-hackers

From Robert Haas
Subject future-proofing relkind tests, take two
Date
Msg-id AANLkTikkjUYxkhsZfVv2PbB-uEjos+hxhqD5Di33v_xL@mail.gmail.com
Whole thread Raw
List pgsql-hackers
Here's another attempt to reduce the number of places in the code that
need to be updated when adding a new relkind.  It adds a few macros --
RELKIND_HAS_STORAGE(), RELKIND_HAS_SYSTEM_ATTS(), and
RELKIND_HAS_SYSTEM_GENERATED_ATTNAMES() and uses them in place of more
ad-hoc tests for the same conditions -- and it rewords a few
problematic messages (some of which are already slightly inaccurate)
so that they won't need updating when we add a new relkind for foreign
tables.

Thoughts?  This is not a complete solution by any means, but I don't
think it makes anything worse (unless you hate the proposed wording, I
suppose) and it has the added benefit of simplifying the code in a few
places.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Avoiding rewrite in ALTER TABLE ALTER TYPE
Next
From: Greg Smith
Date:
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid