Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW] - Mailing list pgsql-hackers

From Michael Glaesemann
Subject Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]
Date
Msg-id CC6E3E20-28B2-450A-A539-E4486D1F4689@seespotcode.net
Whole thread Raw
In response to Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]  (Josh Berkus <josh@agliodbs.com>)
Responses Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]
Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]
List pgsql-hackers
On Sep 16, 2009, at 15:17 , Josh Berkus wrote:

> Michael,
>
>> This is also currently valid:
>>
>> CREATE FUNCTION mod (x int, y int)
>> RETURNS int LANGUAGE plpgsql
>> AS $f$
>> DECLARE
>> z INT := x % y;
>> BEGIN
>>  RETURN z;
>> END; $f$
>>
>> As is this:
>>
>> CREATE FUNCTION mod (x int, y int)
>> RETURNS int LANGUAGE plpgsql
>> AS $f$
>> BEGIN
>>  RETURN (x % y);
>> END; $f$
>
> Certainly.  I was doing that to have a simple example; obviously you
> wouldn't write a mod funciton, and you wouldn't do it in plpgsql.   
> There
> are other case where the lack of mutability in IN parameters causes  
> you
> to create a throwaway variable.

Have an example at hand? I'd argue that in a case of a function of  
more complexity from a code clarity standpoint you'd want to assign to  
a new variable that describes what the new value reflects.

Michael Glaesemann
grzm seespotcode net





pgsql-hackers by date:

Previous
From: tomas@tuxteam.de
Date:
Subject: Re: WIP: generalized index constraints
Next
From: Steve Prentice
Date:
Subject: Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]