Re: Check constraints and function volatility categories

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: Dane Foster <studdugie(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Check constraints and function volatility categories
Date: 2016-02-01 19:56:05
Message-ID: CAKFQuwZ9wxzREa=0tniE4geZjXxkductR2hBGkOXjZTSZmHnMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Feb 1, 2016 at 12:41 PM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 02/01/2016 11:17 AM, Dane Foster wrote:
>
>> Hello,
>>
>> I'm discovering that I need to write quite a few functions for use
>> strictly w/ check constraints and I'm wondering if declaring the
>> volatility category for said functions will affect their behavior when
>> invoked by PostgreSQL's check constraint mechanism.
>>
>
​Adrian's point is spot-on but the important thing to consider in this
situation is that check constraints are assumed to be immutable and if you
implement a check function that is not you don't get to complain what you
see something broken. The nature and use of an immutable check constraint
only has a single dynamic - execute the function using the given values
once for every record INSERT or UPDATE. There is no reason, and I suspect
there is no actual, attempt to even look at the volatility category of said
function before performing those actions. It is possible that two records
inserted or updated in the same query could make use of the caching
possibilities afforded by immutable functions but if so assume it is being
done unconditionally.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Yu Nie 2016-02-01 20:01:02 Re: strange sql behavior
Previous Message melvin6925 2016-02-01 19:45:30 Re: strange sql behavior