Robert Haas <robertmhaas@gmail.com> writes:
> After further thought, I think it makes sense to change this around a
> bit and create a family of functions that can be invoked like this:
> void check_relation_for_FEATURE_support(Relation rel);
That seems like a reasonable idea, but ...
> ... The error message will be of the form:
> constraints can only be used on tables
> triggers can be used only on tables and views
> etc.
> This avoids the need to define a separate error message for each
> unsupported relkind, and I think it's just as informative as, e.g.,
> "constraints cannot be used on <whatever object type you tried to
> invoke it on>". We can adopt the same language for commands, e.g.:
> "CLUSTER can only be used on tables".
ISTM there are four things we might potentially want to state in the
error message: the feature/operation you tried to apply, the name of the
object you tried to apply it to, the type of that object, and the set of
object types that the feature/operation will actually work for. Our
current wording ("foo is not a table or view") covers the second and
fourth of these, though the fourth is stated rather awkwardly. Your
proposal above covers the first and fourth. I'm not happy about leaving
out the object name, because there are going to be cases where people
get this type of error out of a long sequence or nest of operations and
it's not clear what it's talking about. It'd probably be okay to leave
out the actual object type as long as you include its name, though.
One possibility is to break it down like this:
ERROR: foo is a sequenceDETAIL: Triggers can only be used on tables and views.
This could still be emitted by a function such as you suggest, and
indeed that would be the most practical way from both a consistency
and code-size standpoint.
regards, tom lane