Re: Reassign value of IN parameter in 9.1.1 - Mailing list pgsql-general

From Gavin Casey
Subject Re: Reassign value of IN parameter in 9.1.1
Date
Msg-id CAMwtF+pKsLmBNU=BAF5DgY6YvhPE0db=5WrstA1tmszzvO5MHw@mail.gmail.com
Whole thread Raw
In response to Re: Reassign value of IN parameter in 9.1.1  (Alban Hertroys <haramrae@gmail.com>)
Responses Re: Reassign value of IN parameter in 9.1.1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general


On 24 November 2011 14:12, Alban Hertroys <haramrae@gmail.com> wrote:
On 24 November 2011 14:52, Gavin Casey <gpjcasey@googlemail.com> wrote:
> This works in 9.1.1 but seems like a bug to me:
>
> create function xout(_x INTEGER)
> returns integer
> as $$
> begin
>    _x = _x * 2;

I would expect an error here, as having an expression without a
context (an if-statement, for example) should be illegal.

An assignment should be fine though:
  _x := _x * 2;

I'm guessing people make errors like this frequently enough that the
parser was relaxed to accept this expression as an assignment, even
though the syntax for those is slightly different. There is no other
possible explanation for such a line, after all, the author of this
code clearly meant to put an assignment there.

>    return _x;
> end;
> $$ LANGUAGE plpgsql;
>
> select xout(4);

What is the output? I'm guessing it's 8, since there was no syntax
error. That would be the right answer too, in that case.
Function-local variables don't matter outside the function, after all.
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.

It was actually the reassignment of an IN parameter that I was questioning,
the '=' sign on it's own was my typo, apologies for confusion.

pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: Reassign value of IN parameter in 9.1.1
Next
From: Gaëtan Allart
Date:
Subject: Re: General performance/load issue