Re: plpgsql: another new reserved word

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marko Kreen" <markokr(at)gmail(dot)com>
Cc: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Jan Wieck" <JanWieck(at)yahoo(dot)com>, "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql: another new reserved word
Date: 2007-11-26 15:26:24
Message-ID: 14075.1196090784@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Marko Kreen" <markokr(at)gmail(dot)com> writes:
> On 11/10/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Can anyone comment on how Oracle handles cases like this?

> Some googling brought following link:

> http://download-uk.oracle.com/docs/cd/B14117_01/appdev.101/b10807/d_names.htm

Hmm, interesting document. I think the bit that is relevant for us is
the statement

: An outer capture occurs when a name in an inner scope, which once
: resolved to an entity in an inner scope, is resolved to an entity in an
: outer scope. SQL and PL/SQL are designed to prevent outer captures. You
: do not need to take any action to avoid this condition.

AFAICT this means that if there is any ambiguity, the most closely
nested possible interpretation will always win. Therefore the current
behavior of plpgsql is indeed wrong, because it searches up the
namespace stack for block labels too soon. I'll go see about changing
that.

The subsection "Qualifying References to Object Attributes and Methods"
describes some truly bletcherous behavior --- you can't reference a
complex-column component unless you start from a table alias? How
non-orthogonal. I prefer our current solution of making you
parenthesize the column reference before you access its component ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2007-11-26 15:32:24 proposal, plpgsql, 8.4, for record in cursor
Previous Message Tom Lane 2007-11-26 15:02:43 initdb for RC1 (was Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3?)