From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
---|---|
To: | Yann Michel <yann-postgresql(at)spline(dot)de> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com> |
Subject: | Re: Extending System Views: proposal for 8.1/8.2 |
Date: | 2005-01-23 21:34:23 |
Message-ID: | 20050123213423.GX67721@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)decibel(dot)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?"
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-01-23 21:36:18 | Re: Much Ado About COUNT(*) |
Previous Message | Alvaro Herrera | 2005-01-23 21:15:49 | Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED |