| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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 03:11:54 |
| Message-ID: | 173d47e1-3aad-5d59-c902-1715c3ce5bc1@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 1/7/17 8:53 PM, Tom Lane wrote:
> 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.
Sorry, I'm not following... you can override a parameter name the same
way and get the same behavior, no?
BTW, I do wish you could change the label of the scope that arguments
went into, so that you could use that label to refer to function
parameters. If we allowed that it'd perhaps be the best of both worlds:
you'd be guaranteed access to all auto variables and parameters, and
that access wouldn't need to be tied to the function name (which can be
both painful and error prone).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2017-01-08 03:20:41 | Re: pg_background contrib module proposal |
| Previous Message | Peter Geoghegan | 2017-01-08 03:01:51 | Re: ICU integration |