Re: functions: stable/volatile

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

In response to

Browse pgsql-general by date

  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