From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Extending System Views: proposal for 8.1/8.2 |
Date: | 2005-01-21 21:06:28 |
Message-ID: | 20050121210628.GB9033@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 21, 2005 at 12:17:08PM -0800, Josh Berkus wrote:
> Folks,
>
> This is for 8.1, or for 8.2 if we have a no-initdb cycle for 8.1.
>
> I'm proposing to expand both the coverage and number of "system views". Our
> system views are an extremely useful way to get data about the system if
> you're not on PSQL. They are a better idea than using the underlying system
> tables, both becuase the system table output can be kind of cryptic, and
> because the system tables may change but it will be easy to maintain the
> views the same.
>
> Therefore, I want to run my proposed design past the team, because I'd like to
> build system views we can live with for the next 3-4 versions, which will
> allow GUI and library builders to have a reliable, static interface onto the
> system objects. Suggestions & adjustments, please! It shouldn't take me
> long to write these with a clear spec.
>
> (oh, and information_schema really doesn't cover this because the SQL spec is
> rather limited in what objects it describes)
>
> pg_tables
> ADD comment
>
> pg_stats
> ADD statstarget for each column
> (the SET STATISTICS for each column)
>
> pg_user
> ADD groups (array)
>
> pg_functions --> create new view
> schemaname
> functionname
> functionowner
> parameters (array)
> returntype
> functionsettings (things like STABLE)
> functionsource
> comment
>
> pg_views
> ADD comment
>
> pg_columns --> new view **
> schemaname
> tablename
> columnname
> datatype
> typemodifiers (NOT NULL, default, etc)
> comment
>
> pg_aggregates --> new view **
> schemaname
> aggregatename
> aggregateowner
> datatype
> initvalue
> transfunction
> finalfunction
> comment
>
> pg_operators --> new view **
> schemaname
> operatorname
> operatorowner
> operatortype
> datatypes (array)
> operatorfunction
> comment
>
> pg_schemas --> new view
> schemaname
> schemaowner
> defaulttablespace
> comment
>
> pg_triggers --> new view ***
> schemaname
> tablename
> triggername
> triggerowner
> triggerfunction
> conditions (update, insert, etc.)
> modifiers (deferrable, etc.)
> enabled
> comment
>
> pg_foriegnkeys --> new view ****
> parentschema
> parenttable
> parentcolumns (array)
> childschema
> childtable
> childcolumns (array)
>
> Views I think will be wanted by I've not really figured out how to define yet:
> pg_types
> pg_domains
> pg_constraints
> pg_groups
I don't know how this fits in, but it would be *very* nice to have
SQLSTATE meta-information available via SQL. I've sent in a patch for
this.
Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2005-01-21 21:34:58 | TIP9 |
Previous Message | Josh Berkus | 2005-01-21 21:04:48 | Re: [pgsql-hackers] Re: Translations at pgfoundry |