Re: BUG #1956: Plpgsql top-level DECLARE does not share scope

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Karl O(dot) Pinc" <kop(at)meme(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1956: Plpgsql top-level DECLARE does not share scope
Date: 2005-10-14 19:33:12
Message-ID: 20051014193312.GV23883@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Oct 13, 2005 at 04:24:23PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > On Thu, Oct 13, 2005 at 01:30:56PM -0400, Tom Lane wrote:
> >> Basically, DECLARE introduces a new name scope that wouldn't be there
> >> if you didn't say DECLARE. Without some bizarre reinterpretation of the
> >> meaning of a DECLARE at the start of a function, variables automatically
> >> created by plpgsql are going to be in an outer scope surrounding that of
> >> the first DECLARE.
>
> > Another possibility is tracking what level sub-block something is in,
> > and using that to determine if the top-most declare in a function is
> > over-writing something.
>
> BTW, another issue here is that if we did merge the first DECLARE with
> the scope of auto-declared variables, it would be a non backwards
> compatible change. Right now you can do, say,

I wasn't suggesting that we actually merge the scopes; is it possible to
detect over-writing a variable without merging them?

> declare found int;
>
> and it'll override the standard FOUND variable. If we change this then
> you'd get an error. (Of course, it could be argued that that would be
> a Good Thing. But it would inhibit us from adding new auto-declared
> variables that are less central to the language than FOUND, because of
> the risk of breaking existing code.)

I thought we were only talking about throwing a warning, not an error. I
don't think it makes sense to throw an error for any of these cases,
because it could well be what the user wants, but it would be nice to
warn them since there's a good chance it's a mistake (especially in the
top-level).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2005-10-14 21:19:24 Re: [BUGS] Bug#333854: pg_group file update problems
Previous Message C Wegrzyn 2005-10-14 19:15:13 Re: BUG #1962: ECPG and VARCHAR