Re: DROP COLUMN Progress

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: DROP COLUMN Progress
Дата
Msg-id 200207080416.g684GqT11970@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: DROP COLUMN Progress  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Ответы Re: DROP COLUMN Progress  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Re: DROP COLUMN Progress  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Christopher Kings-Lynne wrote:
>         /*
>          * 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...

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

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 




В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: Re: DROP COLUMN Progress
Следующее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: Re: DROP COLUMN Progress