Re: API bug in DetermineTimeZoneOffset()
От | Tom Lane |
---|---|
Тема | Re: API bug in DetermineTimeZoneOffset() |
Дата | |
Msg-id | 3938.1383240620@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: API bug in DetermineTimeZoneOffset() (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: API bug in DetermineTimeZoneOffset()
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > ... So, perhaps, instead of having the code > check session_timezone explicitely, have the caller pass it down. > This consideration probably shouldn't drive a backpatchable fix, > however. Well, it's impossible to do that in a back-patchable way, I'm afraid, because wouldn't you have to pass all three of session_timezone/HasCTZSet/CTimeZone? Actually, it strikes me there might be another way to do this, which is to get rid of HasCTZSet/CTimeZone entirely in favor of consing up some pseudo pg_tz structure that represents the desired semantics when we want a "brute force" setting. I think this code is all leftover from a time when we used the libc timezone routines and did not have a cozy relationship with the tz representation --- but that's ancient history now. Let me go look at that idea. It might break external code that looks directly at HasCTZSet/CTimeZone, but I'll bet there isn't any. regards, tom lane
В списке pgsql-hackers по дате отправления: