Re: COPY and Volatile default expressions

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Jaime Casanova <jaime(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY and Volatile default expressions
Date: 2013-04-15 20:53:51
Message-ID: CA+U5nMJbmCw+dR5AEpr2M7vPkmVtBK2DKXOGMbD0BOKfn7n0og@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 15 April 2013 21:32, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> On Mon, Apr 15, 2013 at 3:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> OTOH, the notion that a UUID generator doesn't touch *any* database
>> state seems like it might be worth treating as a general function
>> property: it's simple to understand and applies to a lot of other
>> volatile functions such as random() and clock_timestamp().
>>
>
> Something like the NO SQL access indication mandated by sql standard?
>
> http://www.postgresql.org/message-id/1267473390.7837.9.camel@vanquo.pezone.net

That would work for UUIDs, random() etc but not for sequences.

So I'll treat this as two separate cases:
* add special case for sequences
* use the NO SQL mechanism, as described, which implies no reads or
writes of database state. We could test that, but its somewhat harder
and we'd need to test for that on entry to any function, which I don't
much like.

Default to current timestamp is also a common use case - thanks for
mentioning that.

Doing it tha way Tatsuo would be able to parse functions more easily
as requested in the linked post.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message anarazel@anarazel.de 2013-04-15 21:06:42 Re: Why are JSON extraction functions STABLE and not IMMUTABLE?
Previous Message Rodrigo Barboza 2013-04-15 20:44:42 Re: Query not using index for user defined type