On Wed, Dec 29, 2010 at 5:14 PM, David Fetter <david@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.linnakangas@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