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