Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group