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?
There are two related features in plpgsql2 project:
1. dynamic SQL sets FOUND variable
2. direct access to processed rows info via variable ROW_COUNT
@1 is incompatible change, @2 is good enough - so we should not to change FOUND, but we can propagate ROW_COUNT instead.