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 gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
