Re: Prepping to break every past release... - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Prepping to break every past release...
Date
Msg-id alpine.GSO.2.00.0903042138260.19361@westnet.com
Whole thread Raw
In response to Prepping to break every past release...  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
On Wed, 4 Mar 2009, Joshua D. Drake wrote:

> Something that continues to grind my teeth about our software is that we
> are horribly inconsistent with our system catalogs.

I'd suggest staring at the gyrations required to do an in-place upgrade, 
then considering how the changes you're suggesting will make that even 
more difficult, until this inconsistency no longer seems very important.

> It seems to me that the best method would be to follow the
> information_schema naming conventions as information_schema is standard
> compliant (right?).

You could make a case for changing pg_tables.tablename to 
pg_tables.table_name, so that it better matched the information_schema. 
But it's not like that general approach makes this problem go away. 
You'll still have pg_class.rel_name or relname, because pg_class contains 
several types of relations:  tables, indexes, etc.  Since that particular 
mismatch is impossible to resolve, you can't completely simplify this area 
no matter how hard you try.  That makes it hard to get excited about just 
reducing the number of inconsistencies here.

> Any DBA worth his salt uses system catalogs. Lowering the barrier on 
> uses these catalogs will lead to better and more useful tools as well.

I would wager that putting 1% of the total effort needed to actually 
change the catalog schema names into a documentation/sample code push in 
this area would give a bigger payback.  I never write catalog stuff from 
scratch anymore; I go back to the same couple of template pieces I always 
end up needing for the various types of joins that always pop up and 
customize from there.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Prepping to break every past release...
Next
From: Stephen Frost
Date:
Subject: Re: Prepping to break every past release...