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