Re: Views, views, views! (long)

On Friday 06 May 2005 13:43, Jim C. Nasby wrote:
> On Fri, May 06, 2005 at 09:08:10AM -0400, Robert Treat wrote:
> > On Thursday 05 May 2005 23:45, Joshua D. Drake wrote:
> > > > I was starting to think this... like this should be a project on
> > > > foundry called "enhanced system views" that would be fairly database
> > > > version independant and people could install into any databases they
> > > > needed them in.
> > >
> > > You mean like:
> > >
> > > http://pgfoundry.org/projects/newsysviews/
> >
> > As Jim points out, their current long term goal is to be a replacement
> > for the current system views (hence *new* system views), and the current
> > project was created to facilitate development. What I am thinking is
> > that the project take on a different goal, mainly that it be an add on
> > that intends to work along side the current system views and be both
> > backward and forward compatible (hence *enhanced* system views). It's a
> > subtle difference.
>
> What I don't like about that idea (assuming you're intending that these
> views are never brought into initdb) is it means that admin tools (like
> psql) then either require the user to install the views by hand, or they
> don't use them and keep doing things the hard (and error-prone) way.
>

Sorry, but I'm still in the "admin tools wont use these" camp since I don't
believe these views can solve an admin tools need to support multiple
versioning within its code. I also don't think it is any harder to learn to
query the system tables than it would be to learn to query these new views
(with a few caevets that I will come back to) and it might actually be
better. If I'm building an admin tool, I have to know that tablespaces
aren't supported on some older versions, and I think it is easier to figure
this out if my query breaks on tablespace information rather than if my query
just silently sends me some special data (NULL?) that I have to interpret to
mean "not supported".

That said, some admin tools already have a requirment that you install some
little piece of schema into your database to support them, they could
include this package along with thier software if they felt strongly about
it.

The cavet I am thinking about from above is things like the relacl bits of
pg_class, which are a total poop to work with. Adding a couple of new system
views to help make that information more transparent would be a good thing.
Actually I am thinkinga couple of parts of this stuff could be used as an
enhancement to the current system views if people weren't interested in a
wholesale replacement.

> But yes, the intention is to continue to support backwards compatability
> as much as possible. Currently I believe that compatability stops at
> versions that don't support schemas, though that could change.

I'm curious, are the queries between various versions actually all that
different? I can't imagine that you can present a stable interface going back
3 versions that is relevant to all three versions that also requires serious
query changes between each version.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL