Re: date/time special values incorrectly cached as constant in plpgsql - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: date/time special values incorrectly cached as constant in plpgsql
Date
Msg-id CAKFQuwYGbpZFHpRSbxsXouFDp5EQQJ6jHpN61dJCtoCjBHSKdQ@mail.gmail.com
Whole thread Raw
In response to date/time special values incorrectly cached as constant in plpgsql  (Tijs van Dam <tijs@thalex.com>)
Responses Re: date/time special values incorrectly cached as constant in plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Sat, Oct 17, 2020 at 4:05 AM Tijs van Dam <tijs@thalex.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.

pgsql-bugs by date:

Previous
From: Tijs van Dam
Date:
Subject: date/time special values incorrectly cached as constant in plpgsql
Next
From: Tom Lane
Date:
Subject: Re: date/time special values incorrectly cached as constant in plpgsql