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


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


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)

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.
Who is Participating?
SurranoConnect With a Mentor System 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.
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
(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

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.
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

moluneAuthor Commented:
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
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.
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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.