Re: [HACKERS] Macros bundling RELKIND_* conditions

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2017-Aug-02, Tom Lane wrote:
>> I think Peter's got the error and the detail backwards. It should be
>> more like
>> ERROR: "someview" cannot have constraints
>> DETAIL: "someview" is a view.
>> If we do it like that, we need one ERROR message per error reason,
>> and one DETAIL per relkind, which should be manageable.

> I support this idea. Here's a proof-of-concept patch that corresponds
> to one of the cases that Ashutosh was on about (specifically, the one
> that uses the RELKIND_CAN_HAVE_STORAGE macro I just added). If there
> are no objections to this approach, I'm going to complete it along these
> lines.

+1

> I put the new function at the bottom of heapam.c but I think it probably
> needs a better place.

catalog/catalog.c contains some functions with roughly this kind of
knowledge, so maybe there?

Also, please declare the argument as "const char *relname"; and
shouldn't we use quotes around the relname in the messages?

> BTW are there other opinions on the RELKIND_HAS_STORAGE vs.
> RELKIND_CAN_HAVE_STORAGE debate? I'm inclined to change it to the
> former.

I like RELKIND_HAS_STORAGE. The other seems to imply that some rels
of a relkind have storage and others don't, which seems like a mess.
(Although maybe foreign tables would act like that?)

regards, tom lane