to_date() marked stable?
I was wondering why we mark to_date() as stable and not immutable? It
seems to have been set to stable in 2006 with this patch:
http://archives.postgresql.org/pgsql-committers/2006-11/msg00264.php
Also, mark to_date() and to_char(interval) as stable; although these
appear not to depend on any GUC variables as of CVS HEAD, that seems a
property unlikely to survive future improvements. It seems best to mark
all the formatting functions stable and be done with it.
Are there people using to_date in indexes or partition functions where
changing it to immutable would be useful? The code seems complete
enough now that we should consider an optimization here.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
I was wondering why we mark to_date() as stable and not immutable?
Do you really want to guarantee that it isn't, and never will be,
affected by timezone, datestyle, lc_time, etc? In particular it seems
likely that somebody will eventually complain that since to_char can
output localized month/day names according to lc_time, to_date should be
able to read them.
Are there people using to_date in indexes or partition functions where
changing it to immutable would be useful?
By definition, there are not, and I don't recall many complaints from
people trying to. On the other hand, if we mark it immutable and then
in future wish to go back to allowing environment dependencies, we will
have to risk breaking working applications.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
I was wondering why we mark to_date() as stable and not immutable?
Do you really want to guarantee that it isn't, and never will be,
affected by timezone, datestyle, lc_time, etc? In particular it seems
likely that somebody will eventually complain that since to_char can
output localized month/day names according to lc_time, to_date should be
able to read them.Are there people using to_date in indexes or partition functions where
changing it to immutable would be useful?By definition, there are not, and I don't recall many complaints from
people trying to. On the other hand, if we mark it immutable and then
in future wish to go back to allowing environment dependencies, we will
have to risk breaking working applications.
OK --- without user requests, it seems pointless to make a change here.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Are there people using to_date in indexes or partition functions where
changing it to immutable would be useful?
I do, but I also create a shell function which sets timezone etc.
locally so that to_date is *really* immutable.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com