Re: [HACKERS] merging some features from plpgsql2 project
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] merging some features from plpgsql2 project |
Дата | |
Msg-id | 14181.1483844037@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] merging some features from plpgsql2 project (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: [HACKERS] merging some features from plpgsql2 project
Re: [HACKERS] merging some features from plpgsql2 project |
Список | pgsql-hackers |
Jim Nasby <Jim.Nasby@BlueTreble.com> writes: > On 1/7/17 5:39 AM, Pavel Stehule wrote: >> I checked current implementation of FOUND variable. If we introduce new >> auto variable ROW_COUNT - exactly like FOUND, then it doesn't introduce >> any compatibility break. > Except it would break every piece of code that had a row_count variable, > though I guess you could see which scoping level the variable had been > defined in. If FOUND were declared at an outer scoping level such that any user-created declaration overrode the name, then we could do likewise for other auto variables and not fear compatibility breaks. Currently, though, we don't seem to be quite there: it looks like FOUND is an outer variable with respect to DECLARE blocks, but it's more closely nested than parameter names. Compare: regression=# create function foo1(bool) returns bool as 'declare found bool := $1; begin return found; end' language plpgsql; CREATE FUNCTION regression=# select foo1(true);foo1 ------t (1 row) regression=# create function foo2(found bool) returns bool as regression-# 'begin return found; end' language plpgsql; CREATE FUNCTION regression=# select foo2(true);foo2 ------f (1 row) Not sure if changing this would be a good thing or not --- was there reasoning behind this behavior, or was it just accidental? regards, tom lane
В списке pgsql-hackers по дате отправления: