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
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
Michael Meskes mes...@postgresql.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
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
Michael Meskes mes...@postgresql.org 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
... 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
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 whether we
On Tue, Oct 7, 2014 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us 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
Chris Bandy bandy.ch...@gmail.com writes:
On Tue, Oct 7, 2014 at 5:05 PM, Tom Lane t...@sss.pgh.pa.us 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
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
On 10/5/14, 5:42 PM, Tom Lane wrote:
Gavin Flower gavinflo...@archidevsys.co.nz 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.
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
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
Gavin Flower gavinflo...@archidevsys.co.nz 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
14 matches
Mail list logo
