| From: | Rod Taylor <rbt(at)zort(dot)ca> |
|---|---|
| To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: BETWEEN Node & DROP COLUMN |
| Date: | 2002-07-05 02:48:06 |
| Message-ID: | 1025837287.250.191.camel@jester |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2002-07-04 at 22:07, Christopher Kings-Lynne wrote:
> > > We could change pg_attribute to another name, and create a view called
> > > pg_attribute that never returned isdropped columns to the client. That
> > > would allow clients to work cleanly, and the server to work cleanly.
> >
> > Another case where having an informational schema would eliminate the
> > whole argument -- as the clients wouldn't need to touch the system
> > tables.
>
> Since postgres has so many features that standard SQL doesn't have (eg.
> custom operators), how are they going to be shown in the information schema?
I would assume we would add pg_TABLE or TABLES.pg_COLUMN as appropriate
and where it wouldn't disturbe normal usage.
If we always put pg columns at the end it shouldn't disturbe programs
which use vectors to pull information out of the DB with a target of *.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2002-07-05 02:54:49 | CLUSTER not lose indexes |
| Previous Message | Christopher Kings-Lynne | 2002-07-05 02:18:45 | Re: BETWEEN Node & DROP COLUMN |