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 20051014193312.GV23883@pervasive.com
обсуждение исходный текст
Ответ на Re: BUG #1956: Plpgsql top-level DECLARE does not share scope  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Postgres logs to syslog LOCAL0
Следующее
От: Tom Lane
Дата:
Сообщение: A couple of ecpg issues in CVS tip