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

On Fri, May 06, 2005 at 05:44:43PM -0400, Robert Treat wrote:
> 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 

I find it hard to believe that it's easier to write a 30 line query
instead of just selecting out of a single view. But, even if an admin
tool does want to 'go direct to the source' and query the system tables,
ISTM that having a reference implementation (the system views) would be
very valuable.

> 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".

Well, these views don't prevent you from using version() to know what is
and isn't supported, but if you can think of other means to indicate
what features are and aren't available I'm all ears.

> 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. 

It's certainly not decided that these views would replace anything. I'm
in favor of always keeping these views in their own schema so that it's
up to the user to decide what exactly they want to query. If they want
stuff out of the current catalog, then use pg_catalog. If they want
these new views, then use pg_sysviews.

There is the possibility of eventually replacing some of the old system
views, but that would be several versions away, if it were to ever
happen. And of course these would not replace the system tables.

> > 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.   

I suggest taking a gander at the '_compat' files at
http://lnk.nu/cvs.pgfoundry.org/251/. Basically, features that are new
in 8.0 (ie: tablespaces) have an abstraction layer. The code under that
layer is version specific, but the code above it is generic. So
_compat74.sql creates a bogus pg_tablespace (though now that I'm
thinking about it, we should probably use a different name for that,
such as _pg_tablespace).

Of course, we could certainly go the route of having completely
different view definitions for different versions, but I'm not sure
that's an improvement.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"