Re: Views, views, views: Summary of Arguments

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