Re: Views, views, views: Summary of Arguments

Folks,

We've meandered a bit on this, so I wanted to summarize the arguments
presented on the new system views to date so that we might have some hope of
consensus before feature freeze.

As I see it, there are 3 main arguments about having the new system views at
all. These obviously need to be settled before we go any further on security
models, column names, etc. Please add if I've missed anyone's arguments,
I'm trying to summarize across 2 weeks of discussion and am obviously not
impartial.

Argument (1): Are the views useful to users?
Pro: Several people, particularly the proposers, contend that they are. They
cite as evidence the popularity of related articles on General Bits,
commercial precedent, and the prevalence of user-created system views.
Mostly, the usefulness is aimed at new users.
Con: A few people say that they are not useful, and that the system tables are
easily understood.

Argument (2): Do they provide sufficiently distinct functionality from the
information_schema?
Pro: The proposers contend that the information_schema, by SQL spec, is
unable to show all PostgreSQL objects in sufficient detail. That the
permissions and uniqueness models are wrong for PostgreSQL, and these things
are not easily fixed by extension without breaking the SQL spec. That we
don't want to confuse the information_schema with PostgreSQL-specific
extensions.
Con: Several people, most notably Peter, contend that much of the new system
views are duplicative of information_schema, and that efforts should be made
to extend infomation_schema instead of providing a parallel interface. That
we should make serious efforts to support a standard rather than developing a
proprietary interface. A few people claimed that there was nothing that
information_schema didn't have, or that users didn't need that information
anyway.

Argument (3): Would the new system views be useful to interface designers?
Pro: Christopher Kings-Lynne said yes for phpPgAdmin. Josh argued that we
need to look at interface designers who are designing for 3rd-party
multi-database products who are not supporting PostgreSQL yet and will be
unlikely to learn the system tables.
Con: Dave Page said no for pgAdmin. Several people pointed out issues with
the idea of maintaining backwards compatibility through abstraction. Others
cited argument (2) in favor of information_schema, above.

... thus, as I see it, the *primary* question is in fact argument (2). That
is, is information_schema sufficient, and if not, can it be extended without
breaking SQL standards? Argument (1) did not seem to have a lot of evidence
on the "con" side, and the strongest argument against (3) is that we should
use information_schema.

Andrew, can you do a more cohesive set of points on the 2nd half of that
question? That is, how much SQL spec would we have to break (other than
extension) to cover all of the stuff that pg_sysviews currently covers?

--
Josh Berkus
Aglio Database Solutions
San Francisco