Re: constraints and sql92 information_schema compliance

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