From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Chris <chris(at)bitmead(dot)com> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: AW: ALTER TABLE DROP COLUMN |
Date: | 2000-10-16 10:01:58 |
Message-ID: | 39EAD216.D6171DD7@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chris wrote:
>
> Hiroshi Inoue wrote:
>
> > When I used Oracle,I saw neither option of DROP
> > COLUMN feature. It seems to tell us that the
> > implementation isn't
> > that easy. It may not be a bad choise to give up DROP
> > COLUMN feature forever.
>
> Because it's not easy we shouldn't do it? I don't think so. The perfect
> solution is lazy updating of tuples but it requires versioning of
> meta-data and that requires a bit of work.
I would prefer the logical/physical numbering + typed tuples
(or is it the same thing ;)
It would give us the additional benefit of being able to move to SQL3-wise
correct CREATE TABLE UNDER syntax with most constraints (primary/foreign key,
unique, ...) carried on automatically if we store the (single-)inheritance
hierarchy in one file.
Others (NOT NULL, CHECK, ...) will need additional check for tuple type.
This does not solve the problem for multiple inheritance, but then we could
cludge most of it by inheriting all from a single root.
I suspect it would still be easier than doing it the other way (by
constructing
UNIONs each time, checking several indexes for uniquenass (or creating a new
index type for indexing several separate relations))
---------------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2000-10-16 10:23:56 | AW: Backup, restore & pg_dump |
Previous Message | Chris | 2000-10-16 09:42:18 | Re: AW: ALTER TABLE DROP COLUMN |