Re: date/time special values incorrectly cached as constant in plpgsql
От | Tom Lane |
---|---|
Тема | Re: date/time special values incorrectly cached as constant in plpgsql |
Дата | |
Msg-id | 119368.1602951496@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: date/time special values incorrectly cached as constant in plpgsql ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: date/time special values incorrectly cached as constant in plpgsql
|
Список | 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
В списке pgsql-bugs по дате отправления: