Re: merging some features from plpgsql2 project

2017-01-08 3:53 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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
>