On Wed, Dec 29, 2010 at 5:14 PM, David Fetter <da...@fetter.org> wrote: > On Wed, Dec 29, 2010 at 04:53:47PM -0500, Robert Haas wrote: >> On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas >> <heikki.linnakan...@enterprisedb.com> wrote: >> > On 29.12.2010 06:54, Robert Haas wrote: >> >> >> >> With the patch: >> >> >> >> rhaas=# cluster v; >> >> ERROR: views do not support CLUSTER >> > >> > "do not support" sounds like a missing feature, rather than a nonsensical >> > command. How about something like "CLUSTER cannot be used on views" >> >> In the latest version of this patch, I created four translatable >> strings per object type: >> >> <blats> do not support %s (where %s is an SQL command) >> <blats> do not support constraints >> <blats> do not support rules >> <blats> do not support triggers >> >> It's reasonable enough to write "CLUSTER cannot be used on views", but >> does "constraints cannot be used on views" seems more awkward to me. >> Or do we think that's OK? > > That particular one looks good insofar as it describes reality. With > predicate locks, etc., it may become untrue later, though :)
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); ...where FEATURE is constraint, trigger, rule, index, etc. The function will be defined to throw an error if the relation isn't of a type that can support the named feature. 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". Comments? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers