On Mon, Dec 20, 2010 at 6:29 AM, Radosław Smogura
wrote:
>
> On Thu, 16 Dec 2010 14:24:27 -0500, Tom Lane wrote:
>>
>> =?utf-8?q?Rados=C5=82aw_Smogura?= writes:
>>>
>>> Tom Lane Thursday 16 December 2010 18:59:56
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
>
> ... This timestam
On Thu, 16 Dec 2010 14:24:27 -0500, Tom Lane wrote:
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
Tom Lane Thursday 16 December 2010 18:59:56
=?utf-8?q?Rados=C5=82aw_Smogura?=
writes:
... This timestamp must be properly encoded
depending if target is WITH TZ or not, but JDBC (and other
clien
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> Tom Lane Thursday 16 December 2010 18:59:56
>> =?utf-8?q?Rados=C5=82aw_Smogura?= writes:
>>> ... 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 knowledg
Tom Lane Thursday 16 December 2010 18:59:56
> =?utf-8?q?Rados=C5=82aw_Smogura?= 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 bac
=?utf-8?q?Rados=C5=82aw_Smogura?= 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 bina
Hi,
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 withou
