Re: Views, views, views: Summary of Arguments - Mailing list pgsql-hackers
From | Thomas F.O'Connell |
---|---|
Subject | Re: Views, views, views: Summary of Arguments |
Date | |
Msg-id | 8366940cf885d1ea857ee51bfe37fc3f@sitening.com Whole thread Raw |
In response to | Re: Views, views, views: Summary of Arguments (Josh Berkus <josh@agliodbs.com>) |
Responses |
Re: Views, views, views: Summary of Arguments
|
List | pgsql-hackers |
I guess I'm having difficulty understanding why the system catalogs themselves and provision of support for information_schema are not sufficient for what exists in core. At one point, there was a stored procedure database for Pl/PgSQL. It seems like a system view service like that could easily be created and maintained independently of what is actually considered the core PostgreSQL distribution. If one of the primary issues is a lack of clarity in the documentation of the system catalogs, then that is certainly something that ought to be addressed. But if another of the primary issues is a need for easier access to the information contained in the system catalogs/information schema, then that can be addressed by a public repository that can certainly be moderated and maintained. Think VPAN (Views of PostgreSQL Archive Network)... -tfo -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC Strategic Open Source: Open Your i™ http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-260-0005 On May 10, 2005, at 12:21 PM, 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? > 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 > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings
pgsql-hackers by date: