Re: Revisiting extract(epoch from timestamp)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, hubert depesz lubaczewski <depesz(at)depesz(dot)com>
Subject: Re: Revisiting extract(epoch from timestamp)
Date: 2012-04-09 18:04:10
Message-ID: 10544.1333994650@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Apr 9, 2012 at 1:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> http://archives.postgresql.org/pgsql-general/2012-01/msg00649.php
>> The above-linked discussion also brings up a different point, which is
>> that extracting the epoch from a timestamptz is an immutable operation,
>> but because it's provided in the context of timestamptz_part we can only
>> mark it stable. (That is correct because the other cases depend on the
>> timezone setting ... but epoch doesn't.) It seems like it might be
>> worth providing a single-purpose function equivalent to extract(epoch),
>> so that we could mark it immutable. On the other hand, it's not
>> entirely apparent why people would need to create indexes on the epoch
>> value rather than just indexing the timestamp itself, so I'm a tad less
>> excited about this angle of it.

> If somebody needs it I'd probably be in favor of doing it. I'm not
> sure I'd do it on spec.

Hmm, I thought depesz was asking for such a function here:
http://archives.postgresql.org/pgsql-hackers/2012-01/msg01690.php
but now that I look more closely, he may have just meant that as an
alternative to touching the existing behavior of timestamp_part.
But providing a new function wouldn't be enough to solve the problem
that timestamp_part's immutability marking is wrong.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2012-04-09 18:10:05 Re: [JDBC] Regarding GSoc Application
Previous Message Tom Lane 2012-04-09 17:49:46 Re: bug in fast-path locking