and it's not a bunny rabbit, either
От | Robert Haas |
---|---|
Тема | and it's not a bunny rabbit, either |
Дата | |
Msg-id | AANLkTimR_sZ_wKd1cgqVG1PEvTvdr9j7zD+3_NPvfaa_@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: and it's not a bunny rabbit, either
(David Fetter <david@fetter.org>)
Re: and it's not a bunny rabbit, either (Itagaki Takahiro <itagaki.takahiro@gmail.com>) |
Список | pgsql-hackers |
In reviewing the work Shigeru Hanada has done on SQL/MED, it's come to my attention that we have a lot of error messages that use the error code ERRCODE_WRONG_OBJECT_TYPE and have text like this: "%s" is not a table "%s" is not an index or even better: "%s" is not a table, view, composite type, or index which, once we have foreign tables, needs to be changed to read: "%s" is not a table, view, composite type, index, or foreign table If we someday add materialized views, it'll need to mention that, too. In the particular case I'm looking at right now (renameatt_internal), a more informative error message might be something like "system-generated attribute names may not be altered", and maybe that's actually a good way to go in that particular case. But it seems somewhat painful to make this work for ATSimplePermissions() and ATSimplePermissionsRelationOrIndex(); in many cases, there's not much to say beyond the fact that the particular alter table subcommand isn't supported by the object type to which the user has attempted to apply it. Still, I'm a bit wondering if there's some more generic way we can phrase the problem. Could we get away with something as simple as "requested operation is not supported for <plural-form-of-object-type>"? In some sense that's less informative, because it doesn't tell you which object types DO support the requested operation, but it's not clear that you care about that. If you are trying to drop a column from a view, the fact that it would be possible to drop a column from a table is cold comfort. The advantage of this method is that you need only N translatable strings (one per relkind), rather than 2^N (one per subset of the universe of relkinds). A slightly more granular version of this would be to make the caller pass in a string indicating what the requested operation actually is, so that you can say something like "<plural-form-of-object-type> do not support <requested-operation>" or "<requested-operation> is not supported by <plural-form-of-object-type>" (e.g. "views do not support SET NOT NULL"). But that breaks our guideline about assembling translatable strings from small pieces. Maybe it'd be OK if the piece is just a fragment of SQL syntax, though - not sure. Or we can just stick with the way we've been doing it, if I'm the only one who thinks it's icky. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: