Josh Berkus wrote:
> a) all view and column names are as explicit and as readable
> as possible (e.g. "type_schema_name", not "typnsname")
I would suggest that you align your terminology with the information
schema as much as possible, so it would be "type_schema" and not
"type_schema_name", and "ordinal_position" instead of
"column_position". Otherwise we'll have a lot of confusion ahead if we
instroduced a third parallel set of terminology.
> c) In most places, "system" objects are segregated from
> "user" objects,
> e.g. pg_user_indexes
I think that is a bad idea as it goes against the fundamental design of
PostgreSQL.
> d) Columns may be added to the system views, but never
> dropped or changed in incompatible ways. Likewise, views will be
> added but not dropped or renamed.
Dave Page already pointed out an example where this is a bad idea. When
a feature is removed, we can't keep claiming it exists.
> g) All views are as normalized as possible, using child views
> rather than arrays, and providing keys and consistent join columns.
You still seem to have a bunch of arrays in there. Anything with an
array is never normalized.
That said, I don't particularly care for this proposal. If you want a
human-readable version of the system catalogs, I suggest you work on
extensions of the information schema, not a completely new interface.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
