On Fri, Feb 16, 2018 at 6:08 AM, mariusz <mar...@mtvk.pl> wrote: > On Fri, 2018-02-16 at 05:40 -0700, David G. Johnston wrote: > > On Fri, Feb 16, 2018 at 5:31 AM, mariusz <mar...@mtvk.pl> wrote: > > > > so, if there is a reason for such a construct and it does > > something i > > didn't notice, please let me know what is the purpose of > > keyword RETURN > > after a valid statement. > > > > > > > > https://www.postgresql.org/docs/10/static/plpgsql- > control-structures.html#PLPGSQL-STATEMENTS-RETURNING > > > yes, i know what RETURN does and when it does not exit from function > (like RETURN NEXT or RETURN QUERY), i know that part of docs, even read > that again and again before sending, but i must be blind, because i > cannot see any mention of > <statement> RETURN; > where that RETURN keyword does nothing (note the lack of ; before > return) > maybe knowing all that i just pass the docs too fast, but i honestly > cannot see why is this allowed. > > the only similar thing which comes to my mind is a statement with > RETURNING ... clause within cte, but it's not the case here (nor the > same spelling) >
Yeah, I failed to grasp the entire question. Pavel's answer covers this; RETURN is not a reserved word and thus it is not an error to use it as a column label - and in this context that is how RETURN is being parsed. Typos that just happen be valid syntax is a general problem in a declarative language like SQL It would be interesting if (some?) queries supplied to the pl/pgsql executor could be made to fail if column or table aliases were present - though at this point it would never be accepted. Maybe something like plpgsql_check (static analyzer) could point these out? David J.
