From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BETWEEN Node & DROP COLUMN |
Date: | 2002-07-04 16:34:35 |
Message-ID: | 3899.1025800475@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Largely-illusory? Almost every pg_attribute query will have to be modified
> for isdropped, while Hiroshi's approach requires so few changes, we are
> having trouble even finding a query that needs to be modified. That's
> pretty clear to me.
Apparently you didn't think hard about the pg_dump example. The problem
there isn't the query so much as it is the wired-in assumption that the
retrieved rows will correspond to attnums 1-N in sequence. That
assumption breaks either way we do it. The illusion is thinking that
clients won't break.
I suspect it will actually be easier to fix pg_dump if we use the
attisdropped approach --- it could keep the assumption that its array
indexes equal attnums, include attisdropped explicitly in the rows
it stores, and just not output rows that have attisdropped true.
Getting rid of the index == attnum assumption will be a considerably
more subtle, and fragile, patch.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-07-04 16:42:51 | Re: Scope of constraint names |
Previous Message | Bruce Momjian | 2002-07-04 16:17:58 | Re: I am being interviewed by OReilly |