From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Views, views, views! (long) |
Date: | 2005-05-05 13:50:28 |
Message-ID: | 22878.1115301028@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Tom,
>> To put it more bluntly: exactly what are you accomplishing here that
>> isn't already accomplished, in a *truly* standard fashion, by the
>> INFORMATION_SCHEMA? Why do we need yet another nonstandard view on
>> the underlying reality?
> To quote myself:
> Q: Why not just use information_schema?
> A: Because the columns and layout of information_schema is strictly defined by
> the SQL standard. This prevents it from covering all PostgreSQL objects, or
> from covering the existing objects adequately to replicate a CREATE
> statement. As examples, there is no "types" table in information_schema, and
> the "constraints" table assumes that constraint names are universally unique
> instead of table-unique as they are in PG.
So? If you want reality, look at the catalogs.
I think that in a release or three, these views will be just as
distorted a representation of the underlying reality as the
information_schema is now. Either that or you'll be changing them
incompatibly. You can't have both truth and a greater degree of
stability than the underlying catalogs.
So my opinion remains "what's the point?". All you have really
accomplished is some editorialization on table/column names.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Anastassia Ailamaki | 2005-05-05 13:54:31 | Re: "Priority Mechanisms for OLTP and Transactional Web Applications" |
Previous Message | Dave Cramer | 2005-05-05 12:55:42 | Re: [pgsql-advocacy] Increased company involvement |