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