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

I'm glad to see a types view. A while ago I was trying to figure out a
way to query the pg_* views to see if a particular function existed. I
quickly got stuck trying to figure out how to properly handle the
arguments array. The solution Tom gave in this case was just to
hard-code the OID for the type I needed. It works, but it seems rather
ugly.

I think it would be good if pg_function included an array of parameter
types of the standard parameter names, as well as the type OIDs.

On Fri, Jan 21, 2005 at 12:17:08PM -0800, Josh Berkus wrote:
> ** = for these three views, there are an enourmous number of system 
> aggregates, operators, etc. ? I'm wondering if I should hide the system ones, 
> or simply trust the user to filter by schema?

I think it would be handy to have a set of views defined that shows
everything, and have the 'normal set' (ie, the views with the easiest
name to type in) defined to hide the system stuff. I suspect that most
of the time people are using these views they don't care about the
system stuff.

> *** = since there will be a seperate FK view, pg_triggers will omit FK 
> constrainttriggers.
I think it would be useful if there was a version of the view that
showed what these triggers were. If you want to see all the triggers
operating on a table, for example.

I guess this is a bit of a grey area, since I don't know of any other
database that handles RI using triggers.

> **** = I've used the non-canon terms "parent" and "child" here. ? The problem 
> is that the standard terms are completely confusing and unintuitive, such as 
> "referring" and "referenced". ? ? Other suggestions are welcome.

I think parent and child is fine.

On another naming note; the naming convention for system stuff has
always driven me nuts. Some the letter prefix (ie: tab for tables) in
front of every field name, with no underscores or anything. Extensive
use of abbreviations that you need to remember (ie: indnatts, indexprs,
indpred). No use of underscores (indisunique). Yet the view and table
names do use underscores.

I realize that there's probably a pretty tight mapping between catalog
*tables* and internals and that changing anything there would probably
have a huge impact on code. Of course there's also existing code that
uses the pg_catalog stuff that's defined today.

What I'm hoping is that with the amount of work involved in the changes
Josh is suggesting, instituting a more rational naming scheme wouldn't
be that much extra effort, at least for things that are being added. One
possibility might be to leave the existing views alone (and possibly
deprecate them), and just create new views. What I'd like to see is
names that are spelled out and underscore delimited.

BTW, this is something I can actually work on myself, and I'd be happy
to work on the code as consensus is reached on what the different views
should look like.

My $2.00.
-- 
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?"