Re: Why *exactly* is date_trunc() not immutable ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alban Hertroys <alban(at)magproductions(dot)nl>
Cc: Michael Glaesemann <grzm(at)seespotcode(dot)net>, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Why *exactly* is date_trunc() not immutable ?
Date: 2007-02-19 15:25:20
Message-ID: 9690.1171898720@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alban Hertroys <alban(at)magproductions(dot)nl> writes:
> What I'm trying to say is not that it _is_ immutable, but that it
> _behaves_ immutable (under said conditions).
> This could imply that if a certain condition is available in a query on
> which such a function operates, it would behave immutable.

Right, but we don't have any way to represent such a fact in
date_trunc's pg_proc entry, so we have to mark it as "not immutable".

There was a related discussion awhile ago when designing the current
set of "what time is it" functions --- transaction_timestamp(),
statement_timestamp(), and clock_timestamp(). The original proposal
had just a single function that took a parameter telling which value
you wanted. The trouble with that was that it'd have had to be marked
volatile, thereby defeating any ability to optimize conditions using it.
By splitting into three functions, we were able to limit the "volatile"
label to clock_timestamp().

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David Legault 2007-02-19 15:32:06 Per Database Roles
Previous Message Edwin Quijada 2007-02-19 14:52:00 RE: postgreSQL