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

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-hackers by date

  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]