Re: Volatile functions in WITH

From: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>
To: Ben Morrow <ben(at)morrow(dot)me(dot)uk>
Cc: pgsql-sql <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Volatile functions in WITH
Date: 2013-02-20 16:10:08
Message-ID: CAL_0b1v0rn48ecG1wcSG1ML+W=pW5-A5yFo7nzXi1NCV8S35XQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Wed, Feb 20, 2013 at 12:19 AM, Ben Morrow <ben(at)morrow(dot)me(dot)uk> wrote:
> That's not reliable. A concurrent txn could insert a conflicting row
> between the update and the insert, which would cause the insert to fail
> with a unique constraint violation.

Okay I think I got it. The function catches exception when INSERTing
and does UPDATE instead, correct?

If you got mixed up with plpgsql anyway what is the reason of making
this WITH query constructions instead of implementing everything in a
plpgsql trigger on DELETE on exp then?

> Yes, I can do experiments too; the alternatives I gave before both work
> on my test database. What I was asking was whether they are guaranteed
> to work in all situations, given that the planner can in principle see
> that the extra table reference won't affect the result.

From the documentation "VOLATILE indicates that the function value can
change even within a single table scan, so no optimizations can be
made". So they are guaranteed to behave as you need in your last
example.

What about optimizing it out in WITH - I would like to listen to
hackers' opinion, because for me it looks like a bug.

--
Sergey Konoplev
Database and Software Architect
http://www.linkedin.com/in/grayhemp

Phones:
USA +1 415 867 9984
Russia, Moscow +7 901 903 0499
Russia, Krasnodar +7 988 888 1979

Skype: gray-hemp
Jabber: gray(dot)ru(at)gmail(dot)com

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Ben Morrow 2013-02-20 18:16:04 Re: Volatile functions in WITH
Previous Message Ben Morrow 2013-02-20 08:19:12 Re: Volatile functions in WITH