On Wed, Oct 22, 2014 at 11:32:41AM -0400, Tom Lane wrote:
> I don't have a strong opinion about which of the above things to do ...
> what's your preference?
I think it's better for the future if me make a clean cut. Yes, the option
keeps compatability a little bit higher, but that doesn't matter
Michael Meskes 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
>> abb
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 times
... and here is a draft patch for the timezone abbreviation data files.
I changed all the abbreviations for which the parent zone had used more
than one GMT offset since 1970. That seemed like a good cutoff to avoid
wasting cycles on ancient history, especially since the IANA people
themselves do
Michael Meskes writes:
> On 15.10.2014 00:26, Tom Lane wrote:
>> * I've not touched ecpg except for cosmetic changes to keep the struct
>> definitions in sync, and to fix the previously-mentioned bogus free()
>> attempt. I doubt that it would be worth teaching ecpg how to access the
>> zic timezo
On 15.10.2014 00:26, Tom Lane wrote:
> * I've not touched ecpg except for cosmetic changes to keep the struct
> definitions in sync, and to fix the previously-mentioned bogus free()
> attempt. I doubt that it would be worth teaching ecpg how to access the
> zic timezone database --- the problem of
I wrote:
> I got interested in the problem discussed in
> http://www.postgresql.org/message-id/20714.1412456...@sss.pgh.pa.us
> to wit:
>> It's becoming clear to me that our existing design whereby zone
>> abbreviations represent fixed GMT offsets isn't really good enough.
>> I've been wondering wh
Chris Bandy writes:
> On Tue, Oct 7, 2014 at 5:05 PM, Tom Lane wrote:
>> + /* use strncmp so that we match truncated tokens */
>> result = strncmp(key, position->token, TOKMAXLEN);
> In your proposal you wanted to remove "crufty code that deals with
> non-null-terminated token strings". Is this
On Tue, Oct 7, 2014 at 5:05 PM, Tom Lane wrote:
typedef struct
> {
> ! char token[TOKMAXLEN + 1]; /* now always null-terminated */
> char type;
> ! int32 value;
> } datetkn;
Being entirely new to this code, "now" makes me think of the "current
timestamp". I think this word can be remove
I wrote:
> 4. I've eyeballed the relevant code a bit, and it seems that the only
> implementation aspect that isn't perfectly straightforward is figuring
> out how to cram a zic timezone reference into a datetkn table entry.
> I suggest that before tackling this feature proper, we bring struct
> da
On 10/6/14, 6:19 PM, Jim Nasby wrote:
FWIW, I agree for timestamptz, but I do wish we had a timestamp datatype that stored the
exact timezone in effect when the data was entered. That can really, REALLY save your
rear if you screw up either timezone in postgresql.conf, or the server's timezone.
On 10/5/14, 5:42 PM, Tom Lane wrote:
Gavin Flower writes:
The use of an /as_at_date/ is far more problematic. The idea relates to
how existing date/times should be treated with respect to the date/time
that a pg database is updated with new time zone data files. In the
simplest form: there w
Gavin Flower writes:
> The use of an /as_at_date/ is far more problematic. The idea relates to
> how existing date/times should be treated with respect to the date/time
> that a pg database is updated with new time zone data files. In the
> simplest form: there would be a function in pg that
On 06/10/14 10:33, Tom Lane wrote:
I got interested in the problem discussed in
http://www.postgresql.org/message-id/20714.1412456...@sss.pgh.pa.us
to wit:
It's becoming clear to me that our existing design whereby zone
abbreviations represent fixed GMT offsets isn't really good enough.
I've be
I got interested in the problem discussed in
http://www.postgresql.org/message-id/20714.1412456...@sss.pgh.pa.us
to wit:
> It's becoming clear to me that our existing design whereby zone
> abbreviations represent fixed GMT offsets isn't really good enough.
> I've been wondering whether we could ch
15 matches
Mail list logo
