Tom,
Hmmm ... so, per you, we can't add extra views covering non-spec objects to
the information_schema (like aggregates) because we can't modify it in any
way. But per Peter we can't add new views to the pg_catalog because we
want people to use information_schema. I sense a catch-22 here.
I doubt Peter really meant that we can't add any new views; in
particular, for information that is not available from the standard
information_schema it's certainly silly to claim that people should go
to information_schema for it. I do see his point that we shouldn't
unnecessarily duplicate functionality that's available in a standardized
view.
Yes, I agree with him on that. However, there's a certain amount of
confusion inspired by the organization that: "If you want to look up the
table's columns go to information_schmea, if you want the table *size*
go to sysviews." But maybe that's unavoidable. Or maybe we could link
the information_schema views into pg_sysviews?
We'd earlier thought that the permissions stuff in information_schema
made is untenable for any real database catalog use. If 03 has fixed
that, though, maybe this can work. AndrewSN?
I do have doubts about adding any large number of add-on views to
pg_catalog, because of the privileged place of that schema in search
paths. It'd be better to put them in a separate schema ("pg_info"
maybe?) where they'd pose less risk of conflicts with user-defined names.
Does newsysviews already do this?
Yes, in our original conception it was the schema pg_sysviews.
--Josh Berkus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
