Re: constraints and sql92 information_schema compliance
От | Tom Lane |
---|---|
Тема | Re: constraints and sql92 information_schema compliance |
Дата | |
Msg-id | 19869.1141058370@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: constraints and sql92 information_schema compliance (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: constraints and sql92 information_schema compliance
Re: constraints and sql92 information_schema compliance |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: >> No way. The entire point of information_schema is that it is standard; >> adding non-spec things to it renders it no better than direct access >> to the PG catalogs. > 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. 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? regards, tom lane
В списке pgsql-hackers по дате отправления: