Обсуждение: Reassign value of IN parameter in 9.1.1

Поиск
Список
Период
Сортировка

Reassign value of IN parameter in 9.1.1

От
Gavin Casey
Дата:
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;
   return _x;
end;
$$ LANGUAGE plpgsql;

select xout(4);

It would not have compiled in version 8.

I came across such a reassignement doing a code review and was surprised it compiled.

Is there a reason for the change in behaviour?


Re: Reassign value of IN parameter in 9.1.1

От
Alban Hertroys
Дата:
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.

Re: Reassign value of IN parameter in 9.1.1

От
Gavin Casey
Дата:


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.

Re: Reassign value of IN parameter in 9.1.1

От
Pavel Stehule
Дата:
Hello

2011/11/24 Gavin Casey <gpjcasey@googlemail.com>:
> 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;
>    return _x;
> end;
> $$ LANGUAGE plpgsql;
>
> select xout(4);
>
> It would not have compiled in version 8.
>
> I came across such a reassignement doing a code review and was surprised it
> compiled.
>
> Is there a reason for the change in behaviour?
>

Read only parameters was confusing for people without knowledge
classic SP languages. Typical programming languages allows it. More
this limit has not real reason in PL/pgSQL and after remove , the
parameters are little bit more usable - try to implement buble sort.

Regards

Pavel Stehule



>
>

Re: Reassign value of IN parameter in 9.1.1

От
Tom Lane
Дата:
Gavin Casey <gpjcasey@googlemail.com> writes:
> It was actually the reassignment of an IN parameter that I was questioning,

That was changed in 9.0, per the release notes:

    * Allow input parameters to be assigned values within PL/pgSQL
    functions (Steve Prentice)

    Formerly, input parameters were treated as being declared CONST,
    so the function's code could not change their values. This
    restriction has been removed to simplify porting of functions
    from other DBMSes that do not impose the equivalent
    restriction. An input parameter now acts like a local variable
    initialized to the passed-in value.

As for := versus =, plpgsql has always accepted both.

            regards, tom lane