On Fri, Nov 1, 2013 at 10:50 AM, Tom Lane wrote:
> I wrote:
>> The second attached patch, to be applied after the first, removes the
>> existing checks of HasCTZSet in the backend. The only visible effect of
>> this, AFAICT, is that to_char's TZ format spec now delivers something
>> useful instea
I wrote:
> The second attached patch, to be applied after the first, removes the
> existing checks of HasCTZSet in the backend. The only visible effect of
> this, AFAICT, is that to_char's TZ format spec now delivers something
> useful instead of an empty string when a brute-force timezone is in u
I wrote:
> So what I'm thinking we should do is internally translate SET TIMEZONE
> with an interval value into a POSIX-style zone name in the above format,
> and then just flush HasCTZSet/CTimeZone and all the special case logic
> around them.
Attached is a set of proposed patches for this.
> 1.
On Thu, Oct 31, 2013 at 2:54 PM, Tom Lane wrote:
> I wrote:
>> 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
I wrote:
> 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.
After some study of the pgtz code, it t
Alvaro Herrera 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 wou
Tom Lane wrote:
> I think that we should change this function to follow the API convention
> used by timestamp2tm(), namely that one passes a NULL pointer if one
> would like session_timezone/HasCTZSet/CTimeZone to control the result.
> A non-null pointer should mean to use that zone specification
DetermineTimeZoneOffset thinks that if the passed pg_tz parameter is
equal to session_timezone, it should pay attention to HasCTZSet/CTimeZone
and allow those to override the pg_tz. The folly of this is revealed by
bug #8572, wherein timestamptz input that explicitly specifies a timezone
name is t
