Re: date/time special values incorrectly cached as constant in plpgsql
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Tijs van Dam <tijs@thalex.com>,
"pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2020-10-17T16:18:16Z
Lists: pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes: > 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. Indeed, but I concur with the OP that 8.5.1.4 doesn't really expend enough words on this point. Perhaps append something like <caution> While the values now, today, tomorrow, yesterday are fine to use in interactive SQL commands, they can have surprising behavior when used in prepared statements, views, or function definitions. In such cases, plan caching can result in a converted specific time value continuing to be used long after it becomes stale. Use one of the SQL functions instead in such contexts. </caution> regards, tom lane
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