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

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> 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.

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