From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Joel Jacobson <joel(at)trustly(dot)com> |
Subject: | Re: merging some features from plpgsql2 project |
Date: | 2017-01-08 02:53:57 |
Message-ID: | 14181.1483844037@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2017-01-08 03:01:29 | Re: [WIP]Vertical Clustered Index (columnar store extension) |
Previous Message | Jim Nasby | 2017-01-08 02:39:24 | Re: merging some features from plpgsql2 project |