Re: Controlling changes in plpgsql variable resolution

Поиск
Список
Период
Сортировка
От Eric B. Ridge
Тема Re: Controlling changes in plpgsql variable resolution
Дата
Msg-id 594AC745-9A4B-49AD-BAC0-2FEA1C468B7D@tcdi.com
обсуждение исходный текст
Ответ на Re: Controlling changes in plpgsql variable resolution  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Oct 19, 2009, at 3:46 PM, Tom Lane wrote:

>> Sorry if this is obvious to everyone else, but *when* will the error
>> throw?
>
> Whenever we do semantic analysis of the particular query or  
> expression.

That's what I figured.

>> During CREATE FUNCTION or during runtime?  I'm secretly hoping
>> that it'll throw during CREATE FUNCTION.
>
> Be careful what you ask for, you might get it ;-)

<snip really good reasons>

Yeah, and we've got at least one function that does the CREATE TEMP  
TABLE foo (...) pattern.  So I understand.

We want to our schema to keep pace with whatever the default settings  
are for stuff like this, so it'd be great if we could find and resolve  
the issues sooner rather than later.  We implemented better coding  
practices later on in the project to help us disambiguate between  
variables and columns, but there's still a bunch of legacy stuff  
that's going to be broken.

eric


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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: LATERAL
Следующее
От: Ron Mayer
Дата:
Сообщение: Could postgres be much cleaner if a future release skipped backward compatibility?