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 19:24:27 |
Message-ID: | 8218.1292527467@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:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> Thursday 16 December 2010 18:59:56
>> =?utf-8?q?Rados=C5=82aw_Smogura?= <rsmogura(at)softperience(dot)eu> 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 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.
No, what I'm saying is that it's complete folly to be sending binary
data for a value you don't know the exact type of. There are too many
ways for that to fail, and too few ways for the backend to validate what
you sent. Adding more possible ways to interpret a binary blob makes
that problem worse, not better.
What you need to fix is the inadequate type bookkeeping in JDBC. If you
don't know the exact type of the value you're going to send, send it in
text mode, where you have some reasonable hope of a mismatch being
detected.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-12-16 19:28:41 | Re: Extensions, patch v18 (merge against master, bitrot-only-fixes) |
Previous Message | Pavel Stehule | 2010-12-16 19:19:17 | proposal: FOREACH-IN-ARRAY (probably for 9.2?) |