Re: Views, views, views! (long) - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Views, views, views! (long)
Date
Msg-id 200505061744.43289.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Views, views, views! (long)  ("Jim C. Nasby" <decibel@decibel.org>)
Responses Re: Views, views, views! (long)  ("Jim C. Nasby" <decibel@decibel.org>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Releases postponed till Monday
Next
From: "Joshua D. Drake"
Date:
Subject: unix_socket_directory bug or feature?