Re: date/time special values incorrectly cached as constant in plpgsql
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tijs van Dam <tijs@thalex.com>
Cc: "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2020-10-17T15:35:32Z
Lists: 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.
Commits
-
Doc: caution against misuse of 'now' and related datetime literals.
- d74ed6fe6e93 9.5.24 landed
- d317fd7570ca 13.1 landed
- c1a3188baeda 9.6.20 landed
- 540849814cdc 14.0 landed
- 3f898c986e39 10.15 landed
- 3753e2720a96 12.5 landed
- 133d06f7bbf5 11.10 landed