I stumbled on another gotcha in 8.3's plpgsql:

create or replace function foobar() returns text as $$
declare
foobar text;
begin return 'ok'; end;
$$ language plpgsql;


Results in error:

ERROR: syntax error at or near "foobar"
LINE 3: foobar text;
^

If this is intentional, then could the error message be made better?

--
marko

Search Discussions

  • Pavel Stehule at Nov 9, 2007 at 11:59 pm

    On 10/11/2007, Marko Kreen wrote:
    I stumbled on another gotcha in 8.3's plpgsql:

    create or replace function foobar() returns text as $$
    declare
    foobar text;
    begin return 'ok'; end;
    $$ language plpgsql;


    Results in error:

    ERROR: syntax error at or near "foobar"
    LINE 3: foobar text;
    ^
    It's label for function's parameters.

    Pavel

    If this is intentional, then could the error message be made better?

    --
    marko

    ---------------------------(end of broadcast)---------------------------
    TIP 3: Have you checked our extensive FAQ?

    http://www.postgresql.org/docs/faq
  • Tom Lane at Nov 10, 2007 at 12:53 am

    "Pavel Stehule" <pavel.stehule@gmail.com> writes:
    On 10/11/2007, Marko Kreen wrote:
    I stumbled on another gotcha in 8.3's plpgsql:
    It's label for function's parameters.
    But now that you mention it, that behavior is a little bit ugly.
    I believe it's a pretty common practice to use a variable named
    the same as the function to hold the eventual function result.
    We've just broken that coding practice.

    It's especially annoying because there isn't any obvious need
    for it: in

    create or replace function foobar() returns text as $$
    declare
    foobar text;
    begin
    foobar := 'ok';
    return foobar;
    end;
    $$ language plpgsql;

    there is no use of "foobar" in a place where a block label would
    be syntactically legal, so it seems like we should be able to
    keep the two types of name separate.

    I think the reason for this may be that there are weird cases where
    things *are* ambiguous. Consider

    << foo >>
    declare bar int;
    begin
    ...
    declare foo record;
    begin
    foo.bar := 42;

    Are we assigning to the outer block's variable bar, or to a field of the
    inner block's variable foo?

    The current plpgsql code seems to be designed to force a qualifier to be
    interpreted as a block label if at all possible, even if there are
    more-closely-nested alternative interpretations; so in the above example
    it would assign to the outer variable bar. This seems a tad bogus
    to me. Can anyone comment on how Oracle handles cases like this?

    regards, tom lane
  • Marko Kreen at Nov 26, 2007 at 10:26 am

    On 11/10/07, Tom Lane wrote:
    The current plpgsql code seems to be designed to force a qualifier to be
    interpreted as a block label if at all possible, even if there are
    more-closely-nested alternative interpretations; so in the above example
    it would assign to the outer variable bar. This seems a tad bogus
    to me. 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

    I have not parsed it completely, but rule seems simple - inner
    scope overrides outer one and no magic on unqualified idents,
    if ident is unqualified, it wont be matched to schema, block
    or some other qualifier. (well, at least no such magic behaviour
    is mentioned.)

    --
    marko
  • Tom Lane at Nov 26, 2007 at 3:26 pm

    "Marko Kreen" <markokr@gmail.com> writes:
    On 11/10/07, Tom Lane 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 9, '07 at 11:49p
activeNov 26, '07 at 3:26p
posts5
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase