Re: Extending System Views: proposal for 8.1/8.2

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

In response to

Responses

Browse pgsql-hackers by date

  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