Re: date/time special values incorrectly cached as constant in plpgsql

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tijs van Dam <tijs(at)thalex(dot)com>
Cc: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: date/time special values incorrectly cached as constant in plpgsql
Date: 2020-10-17 15:35:32
Message-ID: CAKFQuwYGbpZFHpRSbxsXouFDp5EQQJ6jHpN61dJCtoCjBHSKdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Oct 17, 2020 at 4:05 AM Tijs van Dam <tijs(at)thalex(dot)com> wrote:

> If no change is made to the parser, then I'd propose at least a big fat
> warning in section 8.5.1.4 that 'now', 'yesterday', 'today', and 'tomorrow'
> should only be used with the greatest caution, as these values will be
> converted to constants and then cached in unexpected places.
>

IMO, there really isn't anything surprising that these literal inputs end
up converted to constants, which are indeed cached in parts of the system
that utilize a cache, or are stored as the resultant literal instead of an
expression. That's how literal input values work. If I need something to
be dynamic I have to use a volatile function.

I've flagged this one for later consideration and may decide to write a
documentation patch at some point - but as the existing docs aren't wrong
and do cover this dynamic, if maybe not explicitly and thoroughly enough
for some readers, the effort/benefit calculation isn't that high for me.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-10-17 16:18:16 Re: date/time special values incorrectly cached as constant in plpgsql
Previous Message Tijs van Dam 2020-10-17 10:09:20 date/time special values incorrectly cached as constant in plpgsql