On Mon, Feb 27, 2006 at 02:17:03PM -0500, Tom Lane wrote: > Josh Berkus <josh@agliodbs.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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend