2017-01-08 3:53 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > 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? >
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. Regards Pavel > > regards, tom lane >
