Re: BUG #1956: Plpgsql top-level DECLARE does not share scope - Mailing list pgsql-bugs

From Jim C. Nasby
Subject Re: BUG #1956: Plpgsql top-level DECLARE does not share scope
Date
Msg-id 20051014193312.GV23883@pervasive.com
Whole thread Raw
In response to Re: BUG #1956: Plpgsql top-level DECLARE does not share scope  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, Oct 13, 2005 at 04:24:23PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.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@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Postgres logs to syslog LOCAL0
Next
From: Tom Lane
Date:
Subject: A couple of ecpg issues in CVS tip