From: | Rafal Pietrak <rafal(at)zorro(dot)isa-geek(dot)com> |
---|---|
To: | Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: functions: stable/volatile |
Date: | 2006-11-20 22:59:42 |
Message-ID: | 1164063582.5632.59.camel@zorro.isa-geek.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hmmm. Definitly better then my code.
1. does not use the spurious tool_table
2. is surely safe on high traffic and against unintencialnal tool_table
littering.
yet, forces us to write down "SELECT" when we actually mean "UPDATE".
This is sort of 'source code obfuscation' - it's not a very good
practice, but only an aestetics issue. I can live with that.
So, thenx for the hint. I'll surely use it.
-R
On Mon, 2006-11-20 at 16:59 +0100, Tomasz Ostrowski wrote:
> On Mon, 20 Nov 2006, Rafal Pietrak wrote:
>
> > The most obvious construct I'd use is:
> > UPDATE my_table set filed=newvalue WHERE
> > my_function(input)=my_table.selector_field;
> > but it's useless, since the function would have been be evaluated for
> > every row of the table.
>
> -- Not tested
>
> create function update_my_table(newvalue, input)
> returns void
> volatile
> language plpgsql
> as $$
> declare
> selector selector_field_type;
> begin
> selector := my_function(input);
> update my_table set filed=newvalue
> where my_table.selector_field=selector;
> end;
> $$;
>
> -- and then
>
> select update_my_table(newvalue, input);
>
> -- Not tested.
>
> Regards
> Tometzky
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2006-11-20 23:13:10 | Re: More on unique vs distinct |
Previous Message | Casey Duncan | 2006-11-20 22:58:23 | Re: More on unique vs distinct |