Re: DROP COLUMN Progress - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DROP COLUMN Progress
Date
Msg-id 17284.1026138392@sss.pgh.pa.us
Whole thread Raw
In response to Re: DROP COLUMN Progress  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: DROP COLUMN Progress  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: CREATE CONVERSION
Next
From: Thomas Lockhart
Date:
Subject: Re: Proposal: CREATE CONVERSION