• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 481
  • Last Modified:

postgresql proper syntax in order to update several columns by using a function called once

Hello,

The question deals with the syntax to be used in order to update several columns of a table (all rows) using a function that is called once.
Context : postgresql

Example:

Let find_comparison_operator_and_value be a function that split a string into two parts

CREATE OR REPLACE FUNCTION find_comparison_operator_and_value (
IN      my_value_txt character varying,
OUT      comparison_operator character,
OUT      value numeric)
RETURNS record AS
$BODY$

$BODY$
LANGUAGE 'plpgsql';


Let my_table be a table with three columns
CREATE TABLE my_table (
mtb_comparison_operator      character
mtb_value                        character,
mtb_the_value_txt                  character varying
);

Column mtb_the_value_txt of my_table is filled (several rows).

The problem is to update column mtb_comparison_operator  and column mtb_value by using the function.

I found that the following syntax is correct:
UPDATE my_table
SET (mtb_comparison_operator, mtb_value) =
((find_comparison_operator_and_value (mtb_the_value_txt)). comparison_operator,
(find_comparison_operator_and_value (mtb_the_value_txt)). value)

I would like to use another syntax where the function find_comparison_operator_and_value is called once (and executed once).

The following syntax doesn’t work:
UPDATE my_table
SET (mtb_comparison_operator, mtb_value) =
(import. find_comparison_operator_and_value (mtb_the_value_txt))

Thank you in advance for your help.
0
molune
Asked:
molune
  • 3
  • 2
1 Solution
 
SurranoSystem EngineerCommented:
If this function is some kind of stateless parsing function that produces the same output on same input (i.e. uses only the input argument and does not read any table fields inside the pl/pgsql code) then define the function as IMMUTABLE STRICT.

The query may look ugly and redundant but PostgreSQL will be clever enough not to call it twice with same arguments.
0
 
SurranoSystem EngineerCommented:
Well I found a way... but it implies join with the table to be updated on the column not to be updated. If it's not unique it will still work but there may be some unexpected consequences.

UPDATE my_table
SET mtb_comparison_operator = (foo.r).comparison_operator, mtb_value = (foo.r).value
FROM 
(select distinct on (t) 
    m.mtb_the_value_txt t, 
    find_comparison_operator_and_value (m.mtb_the_value_txt) r 
 from my_table m) foo
WHERE foo.t = my_table.mtb_the_value_txt;

Open in new window

0
 
earth man2Commented:
Why not put the update into a separate function.  There you can use plsql variables to store the results of the call to find_comparison_operator_and_value and a cursor to iterate around the table as required.
0
[Webinar] Improve your customer journey

A positive customer journey is important in attracting and retaining business. To improve this experience, you can use Google Maps APIs to increase checkout conversions, boost user engagement, and optimize order fulfillment. Learn how in this webinar presented by Dito.

 
moluneAuthor Commented:
Hello,
Thank you for your answer that I’ll accept.
I’ll label the function as IMMUTABLE STRICT and the optimizer will work. I can use the syntax I found.

Nevertheless ... is there any other syntax or not? If not, why?

After your answer, I’ve read the documentation on IMMUTABLE, STABLE and VOLATILE. Could you give me a link to an example that highlights the problems with potential side effects and use of IMMUTABLE?

Thank you again for your help
0
 
SurranoSystem EngineerCommented:
I don't think IMMUTABLE has any ill effects. It tells the optimiser that it's sufficient to invoke the function only once as long as its result is cached, regardless of the *real* contents of the function body. This could be a problem if the body were not *really* immutable, e.g. you defined it as immutable but did some select (or even worse: insert/update/delete) inside. Luckily, PostgreSQL (I believe all versions 7.4 or later) simply won't allow such statements inside an immutable function's body.

STABLE is effectively same but cache is valid inside the same transaction only. (or something similar, it was sooo long ago :) ). E.g. AFAIK now() is stable (will return the same timestamp throughout the whole transaction regardless of the effective runtime of the transaction) but not immutable (of course).

Description of pg_proc.provolatile explains with some more clarity (hopefully):
provolatile tells whether the function's result depends only on its input arguments, or is affected by outside factors. It is i for "immutable" functions, which always deliver the same result for the same inputs. It is s for "stable" functions, whose results (for fixed inputs) do not change within a scan. It is v for "volatile" functions, whose results may change at any time. (Use v also for functions with side-effects, so that calls to them cannot get optimized away.)

The catch here is that certain function calls, while they are seemingly innocent, depend on some environment and as such they can't be immutable. E.g. string ordering (text_le) may depend on language settings (collate rules) but right now I can't find any good example in PostgreSQL 9.1.
0
 
moluneAuthor Commented:
Surano, I thank you for the attention you pay to answer. I’ll go  further into the issues you showed me. Thank you to earthman2 too.
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now