Hi,
There have been mentions of turning Form_pg_class->relkind into an enum,
so that we can have compilers provide some more help with
switch(relkind) blocks. Here's a quick experiment with that.
The most annoying part of this is that query-generating code uses
CppAsString2() to turn the char values into strings. Making that code
use the enum values directly is quite messy, so before spending real
time into making that correct, I just added some ugly #define
RELKIND_x_STR macros, to substitute the uses of the other construct.
This is not intended to be final form. This is 0001+0002, both
mechanical[1].
0003 is the backend-side change. This looks generally reasonable,
though I'm annoyed that I couldn't find a way to coerce the compiler
into telling me if I had missed some spot. I didn't change any
switch(relkind) blocks (except one in pg_overexplain which causes a
compiler warning for trying to use the non-existent '\0' value), but I
played with a couple of them by removing the default clauses and indeed
we now get warnings for missing cases.
Of course, pg_class.relkind itself (the on-disk catalog) continues to be
a single char with the same values as before.
Does this look more or less a direction we'd like to go in?
[1] git grep --files-with-matches 'CppAsString2(RELKIND' | xargs -n1 perl -pi -e
's/CppAsString2\((RELKIND[^)]*)\)/$1_STR/g'
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Investigación es lo que hago cuando no sé lo que estoy haciendo"
(Wernher von Braun)
