From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal for better support of time-varying timezone abbreviations |
Date: | 2014-10-22 15:32:41 |
Message-ID: | 11467.1413991961@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Meskes <meskes(at)postgresql(dot)org> writes:
> On Wed, Oct 15, 2014 at 09:50:16AM -0400, Tom Lane wrote:
>> The same thought had occurred to me. Probably the main use of the
>> datetime parsing code in ecpg is for interpreting outputs from the
>> server, and (at least by default) the server doesn't use timezone
>> abbreviations when printing timestamps. So maybe that's largely
>> dead code anyhow. I would not propose back-patching such a change,
>> but we could try it in 9.5 and see if anyone complains.
> Agreed on all accounts.
>> A less drastic remedy would be to remove just those abbreviations
>> whose meaning has actually changed over time. Eventually that
>> might be all of them ... but in the meantime, we could at least
>> argue that we weren't breaking any case that worked well before.
> This is what your patch did, right?
No, I did not touch ecpg's set of tokens at all, just changed the
representation of datetktbl to match the new backend coding.
I figured we could discuss behavioral changes separately.
I don't have a strong opinion about which of the above things to do ...
what's your preference?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2014-10-22 15:46:42 | Re: Question about RI checks |
Previous Message | Merlin Moncure | 2014-10-22 15:05:29 | Re: Support UPDATE table SET(*)=... |