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/ ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend