Re: BUG #18007: age(timestamp, timestamp) is marked as immutable, but using age(date, date) says it's not

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Braiam <braiamp(at)gmail(dot)com>
Cc: braiamp+pg(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18007: age(timestamp, timestamp) is marked as immutable, but using age(date, date) says it's not
Date: 2023-06-29 18:24:47
Message-ID: 1576665.1688063087@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Braiam <braiamp(at)gmail(dot)com> writes:
> On Thu, Jun 29, 2023 at 1:52 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> There is no age(date, date) function. What we have is age(timestamp,
>> timestamp) and age(timestamptz, timestamptz), so the parser has to
>> choose which type to coerce to --- and it prefers timestamptz.

> According to \df+ age both timestamptz and timestamp are immutable:

True, but not very relevant: it's the coercion from date that's
giving you trouble.

> So, whatever type is coerced into pre-function evaluation comes
> with strange results. I'm not aware of a way that I can see what
> kind of type is being coerced into.

EXPLAIN will show that, eg

=# explain verbose select age(current_date, current_date);
QUERY PLAN

---------------------------------------------------------------------------------------------------
Result (cost=0.00..0.02 rows=1 width=16)
Output: age((CURRENT_DATE)::timestamp with time zone, (CURRENT_DATE)::timestamp with time zone)
(2 rows)

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Braiam 2023-06-29 18:29:21 Re: BUG #18007: age(timestamp, timestamp) is marked as immutable, but using age(date, date) says it's not
Previous Message Braiam 2023-06-29 18:23:33 Re: BUG #18007: age(timestamp, timestamp) is marked as immutable, but using age(date, date) says it's not