From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Binary timestamp with without timezone |
Date: | 2010-12-16 17:59:56 |
Message-ID: | 23873.1292522396@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?utf-8?q?Rados=C5=82aw_Smogura?= <rsmogura(at)softperience(dot)eu> writes:
> I work on binary support for JDBC. I saw disadventage of TIMESTAMPS WITH /
> WITHOUT TZ. Currently (in text mode) driver always sends date time string with
> appended time offset, as UNSPECIFIED so backend can choose to use offset or
> not. In binary mode I can only send 8 bytes timestamp without appended
> timezone. This timestamp must be properly encoded depending if target is WITH
> TZ or not, but JDBC (and other clients, probably too) doesn't have any
> knowledge about target type when statement is executed
Seems like you need to fix *that*.
> I think about following patch (giving backward compatibility) on timestamp
> (tz). Idea is as follows if we have additional two bytes it's TZ offset and
> use this to convert received time to UTC. I wrote it in e-mail editor (sorry
> :) no C IDE last time),
This is not a terribly good idea, and even if it was, how will you use
it from a client that doesn't know which data type is really in use?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-12-16 18:03:14 | Re: [PATCH] V3: Idle in transaction cancellation |
Previous Message | Robert Haas | 2010-12-16 17:58:32 | Re: directory archive format for pg_dump |