At 15:44 24/01/00 -0400, The Hermit Hacker wrote:
>On Mon, 24 Jan 2000, Tom Lane wrote:
>
>> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> > My idea is as follows.
>>
>> > 1)add a visibile/invisible flag to pg_attribute
>> > 2)DROP COLUMN marks the column as invisible
>> > 3)user interface ignores the columns which are marked invisible
>> > 4)heap_formtuple() etc treats the column as NULL internally
>>
...etc..
>
>Oh, there is a second drawback to it though ...
>
>DROP COLUMN name
>ADD COLUMN name <of a different type>
>
>Then what? :(
Aren't there two separate issues to be resolved:
1. What happens with meta-data referential integrity - a problem for all
implementations.
2. How is it implemeneted.
For my 0.02c, the meta data integrity issue should be resolved by saying
'drop column' is not allowed if there is any (non-system-generated)
metadata that refers to it. Most people (I think) drop columns because they
have no use for them any longer. If they have indexes, constraints,
triggers etc based on those columns, then the drop should fail, since these
items are a prima-facie case that there is a use for them. Cascading
deletes are a nice thing, but for meta-data they can be quite dangerous.
As far as the implementation is concerned, I like the idea of 'hiding' the
deleted column, but am curious: can it be hidden more effectively so that
the only thing that ever sees it is the part of the code that reads it from
disk?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/