Hackers,
The name "relkind" normally refers to a field of type 'char' with values like 'r' for "table" and 'i' for "index". In
AlterTableStmtand CreateTableAsStmt, this naming convention was abused for a field of type enum ObjectType. Often,
suchfields are named "objtype", though also "kind", "removeType", "renameType", etc.
I don't care to debate those other names, though in passing I'll say that "kind" seems not great. The "relkind" name
isparticularly bad, though. It is confusing in functions that also operate on a RangeTblEntry object, which also has a
fieldnamed "relkind", and is confusing in light of the function get_relkind_objtype() which maps from "relkind" to
"objtype",implying quite correctly that those two things are distinct.
The attached patch cleans this up. How many toes am I stepping on here? Changing the names was straightforward and
doesn'tseem to cause any issues with 'make check-world'. Any objection?
For those interested in the larger context of this patch, I am trying to clean up any part of the code that makes it
harderto write and test new access methods. When implementing a new AM, one currently needs to `grep -i relkind` to
finda long list of files that need special treatment. One then needs to consider whether special logic for the new AM
needsto be inserted into all these spots. As such, it is nice if these spots have as little confusing naming as
possible. This patch makes that process a little easier. I have another patch (to be posted shortly) that cleans up
the#define RELKIND_XXX stuff using a new RelKind enum and special macros while keeping the relkind fields as type
'char'. Along with converting code to use switch(relkind) rather than if (relkind...) statements, the compiler now
warnson 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.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company