Alvaro Herrera <alvherre@2ndquadrant.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