From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kyle VanderBeek <kylev(at)yaga(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: JDBC int8 hack |
Date: | 2001-05-08 00:00:53 |
Message-ID: | 24025.989280053@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Kyle VanderBeek <kylev(at)yaga(dot)com> writes:
> On Mon, May 07, 2001 at 07:37:16PM -0400, Tom Lane wrote:
>> The problem is still there, but I think this proposed fix is entirely
>> inappropriate. See prior thread.
> And I, of course, still disagree. There is no ill effect to my patch,
> even once the optimizer gets "fixed". There is no problem caused by the
> explicit (transparent) cast being added by the driver.
At the moment, no, *if* JDBC guesses correctly about whether the hack is
applicable (it's a bit of a leap of logic to assume that the datatype on
the client side necessarily tells you what is being used on the server
side). Otherwise the hack could make performance worse.
But my real objection is that hacks have a way of lingering long after
the problem they solve is gone. I'm particularly concerned about the
fact that a backend deficiency is to be solved by hacking JDBC, which
means that (a) it does no good for people using other client interfaces,
and (b) there could be future problems from people using an old JDBC
with a new backend that doesn't need the hack, and maybe actively
doesn't like it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Lance Taylor | 2001-05-08 05:38:18 | Re: patch for datetime.c |
Previous Message | Bruce Momjian | 2001-05-07 23:54:26 | Re: ODBC cleanup |