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
|
Список | 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 по дате отправления: