Re: psql: bogus descriptions displayed by \d+

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Josh Kupershmidt <schmiddy(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql: bogus descriptions displayed by \d+
Date: 2011-08-13 20:10:47
Message-ID: 3928.1313266247@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On the other hand, I am also not entirely sure such a change in
> terminology would be a net improvement in clarity, even though it does
> seem better in some cases. For example, the CREATE TABLE command does
> not create a viewed table; nor is there any CREATE VIEWED TABLE
> command. On the flip side, for something like CLUSTER, "ERROR: %s is
> not a base table" does seem like it could be more clear than just
> "ERROR: %s is not a table".

> So I'm not sure what to do.

Yeah. Even if the standard is consistent about using "base table"
versus just "table" when they mean a plain table, I do not believe that
that distinction is commonly understood among users. I think people
would tend to think that "base table" means some subset of plain tables,
and would get confused. One fairly likely interpretation would be that
"base table" means the parent table of an inheritance tree, for
instance. If we have to stop and specify what we mean by "base table"
every other time we use the phrase, we have achieved nothing except
pedantry.

On the whole I prefer "table" for plain tables and "relation" for
everything table-ish. We can quibble about whether indexes, say, are
relations within that meaning ... but the PG code and docs have long
used "relation" in the more general meaning, and I doubt that we'll get
far if we try to redefine its meaning now.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kääriäinen Anssi 2011-08-13 20:35:14 Re: index-only scans
Previous Message Robert Haas 2011-08-13 19:52:15 Re: our buffer replacement strategy is kind of lame