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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
