Re: psql: bogus descriptions displayed by \d+

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: psql: bogus descriptions displayed by \d+
Дата
Msg-id 1312482375.24208.22.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: psql: bogus descriptions displayed by \d+  (Josh Kupershmidt <schmiddy@gmail.com>)
Ответы Re: psql: bogus descriptions displayed by \d+  (Robert Haas <robertmhaas@gmail.com>)
Re: psql: bogus descriptions displayed by \d+  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
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 to someone new who doesn't know much about the PostgreSQL jargon,
neither "table" nor "relation" are very precise at all.

But I would suggest that there is more support outside of PostgreSQL
jargon for finding that replacing "table" by "relation" does not
increase precision.

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.

So the bottom line is, I would avoid the term "relation" and look for
other ways to add clarity and precision to the documentation.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Transient plans versus the SPI API
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: psql: bogus descriptions displayed by \d+