From: | Ed Loehr <eloehr(at)austin(dot)rr(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Well, then you keep your darn columns |
Date: | 2000-01-24 18:13:56 |
Message-ID: | 388C9664.1D975D2D@austin.rr.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Let's see: DROP COLUMN would have to mark the column invisible, remove
> any associated constraints (particularly NOT NULL) and indexes, and
> it'd be done. The parser would then have to ignore the column when
> doing column name lookups or expansion of '*', and it would have to
> insert a NULL value for the column when transforming INSERT or UPDATE.
> And that'd be just about it. I like it.
How would you handle multi-column indices that included the column
being dropped? E.g.,
create unique index foobar on mytable(foo,bar);
where the 'bar' column is then dropped...
Dropping all of that index would seem to be problematic.
Cheers,
Ed Loehr
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-24 18:17:57 | Re: AW: [HACKERS] Some notes on optimizer cost estimates |
Previous Message | Tom Lane | 2000-01-24 18:13:45 | Re: [HACKERS] Some notes on optimizer cost estimates |