Re: Happy column adding (was RE: [HACKERS] Happy column dropping)

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

In response to

Responses

Browse pgsql-hackers by date

  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