Robert Haas <robertmh...@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 sequence DETAIL: 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers