Обсуждение: 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 theseappear not to depend on any GUC variables as of CVS HEAD,that seems aproperty unlikely to survive future improvements. It seems best to markall the formatting functions stableand 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