Re: constraints and sql92 information_schema compliance

On Mon, Feb 27, 2006 at 02:17:03PM -0500, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > 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 could, but I'd argue that this makes sense only if the added
> PG-specific stuff looks like a seamless extension of the standard
> definitions. If there are obvious differences in naming style, table
> layout, etc, I'd expect such a setup to look more like a hodgepodge
> than a good idea.

Agreed. Currently, newsysviews uses a completely different naming
scheme, one intended to be as self-explanitory as possible and not using
things like hard to remember abbreviations crammed together without
underscores (no offense to the catalogs; I'm sure backend developers
don't want to type out full names all the time, but it does make it
substantially harder to grok for newer users).

Personally, I find info_schema somewhat hard to use as well, largely
because it's meant to be the same for any database, so there's
terminology mapping you have to do. Plus, newsysviews has some things
that make it easier on people who are doing ad-hoc queries, such as _all
as well as _user versions of most things. So I'd rather keep the naming
we use in newsysviews, but I can certainly see where a version of
info_schema that's been extended could be of use. Perhaps there's reason
to have both. Hopefully an extended info_schema would be able to rely
mostly on what's already in info_schema, so there would be a minimal
amount of work required on it. For that matter, if newsysviews became
part of the standard install, it could well be easier to build
info_schema on it instead of the base tables.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461