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

From Steve Prentice
Subject Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]
Date
Msg-id 42C79B2E-5796-4237-B274-A327F43C1F04@cisco.com
Whole thread Raw
In response to Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]  (Michael Glaesemann <grzm@seespotcode.net>)
List pgsql-hackers
> On Sep 16, 2009, at 12:44 PM, Michael Glaesemann wrote:
>
>> 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.

I can't say I disagree with you from a purist standpoint, but for  
porting existing code sometimes it's more efficient to port what you  
have without rewriting it. In some of the code I'm looking at porting,  
this is a very simple example of a common pattern I'm seeing:

create function create_some_object(pobjectid uuid, psomefkobjectid  
uuid) returns uuid as $$
beginif pobjectid is null then    pobjectid := newid()end ifif psomefkobjectid is null then    select objectid into
psomefkobjectidfrom somefktable where whatever;end if-- create the objectreturn pobjectid
 
end;

-Steve


pgsql-hackers by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]
Next
From: Heikki Linnakangas
Date:
Subject: Re: Feedback on getting rid of VACUUM FULL