Robert Haas <robertmhaas@gmail.com> writes:
> That seems to me to be just confusing the issue. Now the table name
> and the view name are just totally different with no obvious
> connection between them. We have enough nonsense of this type already
> (e.g. pg_stats vs. pg_statistic; pg_authid vs. pg_roles vs.
> pg_shadow). I think we need to settle on a system for handling
> problems of this type and document it in the fine manual or perhaps a
> README somewhere, and stick with it. Inventing random unconnected
> names is just craziness.
Actually, to the extent that we have any convention at all, it's
to use plurals for system view names (pg_tables, pg_views, etc)
and singular for underlying catalogs (pg_index). The only exception
to this on the catalog side is pg_auth_members, which is arguably
misnamed. (pg_inherits is sort of an exception, but it's weird in a
different way: its name is a verb not a noun.) The apparent exceptions
on the view side (pg_group, pg_shadow, pg_user) are actually views that
are backward compatible substitutes for former catalogs, so they are not
really intentional exceptions.
Now it's also the case that we've tended to use tech-speak names
for catalogs (eg, pg_class, pg_namespace not pg_table, pg_schema)
and so that gives us an additional degree of separation between
those names and the more user-facing names chosen for views.
What we seem to be lacking in this case is a good tech-speak
option for the underlying catalog name. I'm still not happy
with having a catalog and a view that are exactly the same
except for "s", especially since as Alvaro notes that won't
lead to desirable tab-completion behavior. OTOH, we have
survived with pg_index vs pg_indexes, so maybe it wouldn't
kill us.
BTW, have we thought much about the simplest possible solution,
which is to not have the view? How badly do we need it? Seems
like dropping the functionality into a psql \d command might be
a viable alternative.
regards, tom lane
