Jim Nasby <jim.na...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers