Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW]
От | Steve Prentice |
---|---|
Тема | Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW] |
Дата | |
Msg-id | 42C79B2E-5796-4237-B274-A327F43C1F04@cisco.com обсуждение исходный текст |
Ответ на | Re: PATCH: make plpgsql IN args mutable (v1) [REVIEW] (Michael Glaesemann <grzm@seespotcode.net>) |
Список | 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 по дате отправления: