Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> writes:
> On 06/27/2013 01:42 PM, Tom Lane wrote:
>> That will break things: CURRENT_DATE will then be equivalent to just
>> writing today's date as a literal.
> Interesting. I tested it by creating a view and a table with a default,
> and it always seems to get translated to:
> ('now'::text)::date
Yeah, that is what the parser does with it. The way to read that is
"a constant of type text, containing the string 'now', to which is
applied a run-time coercion to type date". The run-time coercion is
equivalent to (and implemented by) calling text_out then date_in.
If date_in is marked immutable, then the planner will correctly conclude
that it can fold the whole thing to a date constant on sight. Now you
have a plan with a hard-wired value for the current date, which will
begin to give wrong answers after midnight passes. If your usage
pattern is such that no query plan survives across a day boundary,
you might not notice ... but it's still wrong.
> ... What's interesting is that EnterpriseDB has
> their own pg_catalog.current_date function that gets called by the
> CURRENT_DATE keyword.
Yeah, we really ought to do likewise in the community code. But that
doesn't affect the fundamental semantic issue here, which is that you
can't mark the expression immutable without creating incorrect cached
plans.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
