Re: DROP COLUMN Progress - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: DROP COLUMN Progress
Date
Msg-id GNELIHDDFBOCMGBFGEFOAEABCDAA.chriskl@familyhealth.com.au
Whole thread Raw
In response to Re: DROP COLUMN Progress  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: DROP COLUMN Progress
List pgsql-hackers
> OK, my guess is that it is checks in parser/.  I would issue each of
> these queries with a non-existant column name, find the error message in
> the code, and add an isdropped check in those places.

OK, I think I've narrowed it down to this block of code in scanRTEForColumn
in parse_relation.c:
       /*        * Scan the user column names (or aliases) for a match. Complain if        * multiple matches.
*/      foreach(c, rte->eref->colnames)       {               /* @@ SKIP DROPPED HERE? @@ */               attnum++;
          if (strcmp(strVal(lfirst(c)), colname) == 0)               {                       if (result)
              elog(ERROR, "Column reference \"%s\" is
 
ambiguous", colname);                       result = (Node *) make_var(pstate, rte, attnum);
rte->checkForRead= true;               }       }
 


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...

Comments?

Chris





pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: BlockNumber fixes
Next
From: Bruce Momjian
Date:
Subject: Re: DROP COLUMN Progress