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()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Get more from indices.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Add accurate option to pgbench