Re: AW: ALTER TABLE DROP COLUMN

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

In response to

Browse pgsql-hackers by date

  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