From: | Michael Glaesemann <grzm(at)seespotcode(dot)net> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW] |
Date: | 2009-09-16 19:44:04 |
Message-ID: | CC6E3E20-28B2-450A-A539-E4486D1F4689@seespotcode.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Prentice | 2009-09-16 20:16:21 | Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW] |
Previous Message | tomas | 2009-09-16 19:40:44 | Re: WIP: generalized index constraints |