Re: Extending System Views: proposal for 8.1/8.2 - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Extending System Views: proposal for 8.1/8.2
Date
Msg-id 20050123213423.GX67721@decibel.org
Whole thread Raw
In response to Re: Extending System Views: proposal for 8.1/8.2  (Yann Michel <yann-postgresql@spline.de>)
Responses Re: Extending System Views: proposal for 8.1/8.2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I'm going to reply to 3 emails in one here...

Out of Josh's 4 options, I think a new schema makes the most sense.
Start with a clean plate. Yes, we'll end up with an ugly schema name,
but after the exiting pg_catalog is removed in a few versions, we can go
back to pg_catalog.

The idea of using a GUC to control which version of the schema you get
is also very interesting, though I don't know how workable it is. It
does have a downside, though... if you have a bunch of code that's using
pg_catalog, you'd have no choice but to migrate all of it at once. If
you have both the old and new versions of these tables/views present at
the same time then you can slowly migrate that code over.

Only adding columns to the existing views/tables is also an interesting
possibility. One issue is that it probably wouldn't work very well for
the tables in pg_catalog, though I guess SELECT rules could be written
to handle those. The other issue is that while SELECT * in code is
almost always a bad idea, SELECT * is human-friendly. I suspect that
basically every field in the existing tables/views will be renamed,
which means SELECT * in psql will now give you 2x the number of columns
you need. Though, this could be avoided by having a seperate set of
'human-readable' views. Having a seperate set of human-readable views
would also mean we could provide more human-friendly formatting in one
version, while the other version has everything you'd need to make it
the most useful from a programatic standpoint. An example that comes to
mind is the earlier discussion about function parameters. In a
human-readable version of pg_function, you'd probably just want
schema_name, function_name, parameters[], and return_type, where both
parameters[] and return_type would be the name of the types. But if
you're looking at functions programatically, it would be good to also
have parameter_oids[] and return_type_oid.

Personally, I'm leaning towards option 3: add new fields to pg_catalog.*
to support the new naming convention and new features, and add pg_human.
-- 
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?"


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Much Ado About COUNT(*)