Tom Lane <tgl@sss.pgh.pa.us> Thursday 16 December 2010 18:59:56
> Radosław Smogura <rsmogura@softperience.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 don't say it's bad way to send timestamps in text mode. It's good solution,
because timestamp without tz will silently ignore tz offset, timestamp with tz
will use offset in calculations if it is there, if no it will use server TZ.
> > 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?
Binary protocol disallow to send timezone offset, as text mode allow (lack of
information). I would like to send this in same behavior as text mode does:
send local time with two bytes of client tz as OID unspecified.
One more instead of pq_copymsgbtes better will be tzOffset = pq_getint(buf,
sizeof(int16));
Kind regards,
Radosław Smogura
http://www.softperience.eu