| From: | Steve Prentice <prentice(at)cisco(dot)com> | 
|---|---|
| To: | Michael Glaesemann <grzm(at)seespotcode(dot)net> | 
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW] | 
| Date: | 2009-09-16 20:16:21 | 
| Message-ID: | 42C79B2E-5796-4237-B274-A327F43C1F04@cisco.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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 $$
begin
	if pobjectid is null then
		pobjectid := newid()
	end if
	
	if psomefkobjectid is null then
		select objectid into psomefkobjectid from somefktable where whatever;
	end if
	
	-- create the object
	return pobjectid
end;
-Steve
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-09-16 20:53:57 | Re: Feedback on getting rid of VACUUM FULL | 
| Previous Message | Michael Glaesemann | 2009-09-16 19:44:04 | Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW] |