Re: DROP COLUMN Progress

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: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DROP COLUMN Progress
Date: 2002-07-08 14:26:32
Message-ID: 17284.1026138392@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:
> Christopher Kings-Lynne wrote:
>> I'm thinking that I should put a 'SearchSysCacheCopy' where my @@ comment is
>> to retrieve the attribute by name, and then do a check to see if it's
>> dropped. Is that the best/fastest way of doing things? Seems unfortunate
>> to add a another cache lookup in every parsed query...

> I am still looking but perhaps you could supress dropped columns from
> getting into eref in the first place.

That was my first thought also, but then the wrong attnum would be used
in the "make_var". Ugh. I think what Chris needs to do is extend the
eref data structure so that there can be placeholders for dropped
attributes. Perhaps NULLs could be included in the list, and then the
code would become like

attnum++;
if (lfirst(c) && strcmp(strVal(lfirst(c)), colname) == 0)
...

This would require changes in quite a number of places :-( but I'm not
sure we have much choice. The eref structure really needs to line up
with attnums.

Another possibility is to enter the dropped attnames in the eref list
normally, and do the drop test *after* hitting a match not before.
This is still slow, but not as horrendously O(N^2) slow as Chris's
original pseudocode. I'm not sure how much work it'd really save though;
you might find yourself hitting all the same places to add tests.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2002-07-08 14:28:58 Re: I am being interviewed by OReilly
Previous Message Tom Lane 2002-07-08 14:19:08 Re: BlockNumber fixes