Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]

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

In response to

Responses

Browse pgsql-hackers by date

  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