On Fri, Feb 16, 2018 at 6:08 AM, mariusz <marius@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 <marius@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?
