Re: Views, views, views: Summary of Arguments - Mailing list pgsql-hackers

From David Fetter
Subject Re: Views, views, views: Summary of Arguments
Date
Msg-id 20050510183030.GA23205@fetter.org
Whole thread Raw
In response to Re: Views, views, views: Summary of Arguments  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Tue, May 10, 2005 at 10:21:06AM -0700, Josh Berkus wrote:
> 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?

I've used some of them already at work :)

> 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.

Anybody who contends that the system tables are easily understood is
more than welcome to use this understanding, and will not be impeded
by the existence of things they don't choose to use.  The
aforementioned understanding--quite rare, but that's almost beside the
point--is not an argument for keeping tools out of the hands of people
for whom the internals of the PostgreSQL implementation are not
intuitively obvious.

> 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,

Not by a long, long way.

> and if not, can it be extended without breaking SQL standards?

The information schema, by its nature, cannot contain information
about things like indexes because that would be implementation-
specific information, and the information schema is, by design,
implementation-neutral.

Just my $.02 :)

Cheers,
D
-- 
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: FW: Views, views, views! (long)
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Table Partitioning, Part 1