From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Happy column adding (was RE: [HACKERS] Happy column dropping) |
Date: | 2000-01-25 22:38:22 |
Message-ID: | 200001252238.RAA25731@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> It occurs to me that in at least some of the places where attribute
> numbers are currently used, we ought to use *neither* logical nor
> physical column position, but rather a permanent unique ID --- the
> attribute tuple's OID would work, if it's assigned soon enough to be
> used for constraints given in CREATE TABLE. (Otherwise we could assign
> "column serial numbers" that count from 1 for each relation, but are
> never changed or recycled within the relation.)
>
> In particular, if parsetrees for stored rules and constraints worked
> that way, renumbering attributes that follow the added/dropped column
> would become a lot less painful.
I am going to object to any use of invisible columns just to get a nice
ALTER DROP COLUMN capability. It doesn't seeem with the added code
complexity. Our code is complex enough. Why add more to it just for
one feature.
--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-25 23:01:36 | Re: Happy column adding (was RE: [HACKERS] Happy column dropping) |
Previous Message | Bruce Momjian | 2000-01-25 22:35:32 | Re: [HACKERS] Re: [SQL] DISTINCT ON: speak now or forever hold your peace |