Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


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

Posted on 2014-02-10
Medium Priority
Last Modified: 2014-02-11

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.
Question by:molune
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2

Accepted Solution

Surrano earned 1200 total points
ID: 39849403
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.

Expert Comment

ID: 39849432
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

LVL 22

Expert Comment

by:earth man2
ID: 39849472
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.
Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.


Author Comment

ID: 39849513
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

Expert Comment

ID: 39849844
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.

Author Comment

ID: 39850096
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.

Featured Post

Learn how to optimize MySQL for your business need

With the increasing importance of apps & networks in both business & personal interconnections, perfor. has become one of the key metrics of successful communication. This ebook is a hands-on business-case-driven guide to understanding MySQL query parameter tuning & database perf

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Best database to use for Maps is PostgreSQL. This is an open source database. Comes as a package with most Linux OS. For more info visit the following site: ( This requires some add-o…
By, Vadim Tkachenko. In this article we’ll look at ClickHouse on its one year anniversary.
Steps to create a PostgreSQL RDS instance in the Amazon cloud. We will cover some of the default settings and show how to connect to the instance once it is up and running.
Have you created a query with information for a calendar? ... and then, abra-cadabra, the calendar is done?! I am going to show you how to make that happen. Visualize your data!  ... really see it To use the code to create a calendar from a q…
Suggested Courses

722 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question