Re: [HACKERS] plpgsql: another new reserved word
"Marko Kreen" <[EMAIL PROTECTED]> writes: > On 11/10/07, Tom Lane <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] plpgsql: another new reserved word
On 11/10/07, Tom Lane <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] plpgsql: another new reserved word
"Pavel Stehule" <[EMAIL PROTECTED]> writes: > On 10/11/2007, Marko Kreen <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] plpgsql: another new reserved word
On 10/11/2007, Marko Kreen <[EMAIL PROTECTED]> 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 > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] plpgsql: another new reserved word
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq