Re: DROP COLUMN Progress

Поиск
Список
Период
Сортировка
От Christopher Kings-Lynne
Тема Re: DROP COLUMN Progress
Дата
Msg-id GNELIHDDFBOCMGBFGEFOAEABCDAA.chriskl@familyhealth.com.au
обсуждение исходный текст
Ответ на Re: DROP COLUMN Progress  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: DROP COLUMN Progress  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: BlockNumber fixes
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: DROP COLUMN Progress