Re: psql: bogus descriptions displayed by \d+ - Mailing list pgsql-hackers

On Thu, Aug 4, 2011 at 2:26 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On ons, 2011-07-27 at 17:57 -0400, Josh Kupershmidt wrote:
>> > I think table_name is fine, and if you are very worried, add below
>> that
>> > a table_name also includes views (or whatever).
>>
>> It includes tables, views, composite types, and foreign tables. Is
>> "table" really an appropriate description for all those objects?
>
> Well, the facts are:  According to the SQL standard, "table" includes
> views and foreign tables.  According to scientific-ish database
> literature, a table is a relation and vice versa.

So what are you supposed to call it if you mean, specifically, a table?

> So to someone new who doesn't know much about the PostgreSQL jargon,
> neither "table" nor "relation" are very precise at all.

That can be fixed by defining them better, of course...

> And indeed, even if you know the PostgreSQL jargon, "relation" means
> anything stored in pg_class.  And in almost all cases, a given command
> does not successfully operate and any kind of pg_class object.  So using
> "relation" here creates some kind of illusion that will eventually fail,
> forcing the user to manually figure out what actually works.

This argument doesn't impress me much, because it would be true of any
word we used here.  If we start using "table" to mean "a table, view,
or foreign table", then we're going to have to clarify that CLUSTER
only runs on tables that are actually, uh, tables.  And what about the
error messages that say "x is not a table or view"?

And, moreover, at least in English, it's common to make a statement
about a broader class of objects that does not necessarily apply to
every type of object in the class.  When I tell my wife "your cooking
is delicious", my statement is not intended to include her
tomato-and-vodka sauce, which IMHO is really terrible.  She doesn't
react with confusion and say "but wait, how can you say you like my
cooking when I know that you don't like my tomato-and-vodka sauce?";
rather, she understands that I'm talking about some probably fairly
broad subset of her cooking and that if she wants to know what I think
of a specific dish, she will need to inquire specifically about that
dish.  Similarly, I believe users will understand that when they see
relation_name, they might need to check the detailed description to
know which relation types are included.

I'm not averse to using some better terminology; I agree that relation
is kind of corny.  But if we're going to make an effort to be
consistent here, we need to come up with something that's actually
better, and then hopefully implement it fairly broadly.  We've fallen
into saying "relation" mostly for lack of a better term, but we can't
start getting rid of it until we have a replacement.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company