Re: BUG #1956: Plpgsql top-level DECLARE does not share scope
От | Jim C. Nasby |
---|---|
Тема | Re: BUG #1956: Plpgsql top-level DECLARE does not share scope |
Дата | |
Msg-id | 20051013201226.GJ23883@pervasive.com обсуждение исходный текст |
Ответ на | Re: BUG #1956: Plpgsql top-level DECLARE does not share scope (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #1956: Plpgsql top-level DECLARE does not share scope
|
Список | pgsql-bugs |
On Thu, Oct 13, 2005 at 01:30:56PM -0400, Tom Lane wrote: > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > Based on all that, I would certainly be in favor of throwing a warning > > if you over-define something, since 99% of the time it's a mistake. Is > > that possible with the current checking we do at compile time? > > Without having looked at the code, I imagine the problem is that we > can't tell this situation from an ordinary nested DECLARE block, > that is > > declare x int; > begin > ... > declare x float; > begin > ... > > The above is legal code and I don't think we should throw a warning for > it. > > 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. Yeah, I agree that in the legitimate case it makes much less sense to throw an error. Are blocks that aren't explicitely labled assigned a machine-generated label? If so then it should be possible to tell if something is in the outer-most block or if it's part of the function declaration itself. But I have no idea how difficult it would be to do that. 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. -- 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 по дате отправления: