Re: statement's hashCode()

Felipe,

I wouldn't consider accepting a patch like this for the following reasons:

1) This is functionality not specified by the jdbc spec.

2) This functionality isn't exposing some special postgres feature that
doesn't map into the jdbc spec.

3) As Dave already pointed out, any implementation of this will be
fraught with problems, there are so many corner cases that I don't think
can be handled correctly that the long term support of this will be a
problem.

4) I think the proposed functionality actually violates the contract of
hashcode() since calling other methods on the object will cause the
hashcode to change.  This could cause problems when for example the
object was placed in a hashtable with one key, but then later when
accessed it had a different key.

5) There is no stated reason why this functionality is a good idea.  If
some compelling reason can be made why this is a great feature and will
be used by lots of users so that it is worth the long term cost of
maintaining it once the original developer is long gone, then I am
willing to listen.

thanks,
--Barry


Felipe Schnack wrote:
>   This is exactly what I want!!!
>   Would you accept this patch? :-)
>
> On Thu, 2002-12-26 at 15:07, Dave Cramer wrote:
>
>>Felipe,
>>
>>
>>What you could do is return hashCode() on the stringbuffer.toString() of
>>the query. This would be highly dependant on when it was called however.
>>
>>assuming you wanted to know if they were equal after all of the setXXX
>>methods were called than this would work.
>>
>>
>>Dave
>>On Thu, 2002-12-26 at 11:52, Felipe Schnack wrote:
>>
>>>  I'm writing some routines that could be improved vastly if I had a
>>>hash to identify an AbstractJdbc1Statement. What I need is a method that
>>>returns me an equal value when two instances of the Statement class have
>>>the same SQL query and parameters.
>>>  I just took a look at the sources and noted that right now this class
>>>(AbstractJdbc1Statement) does not implement a custom hashCode()
>>>function... Maybe some of you experts in its implementation could give
>>>me some tips about how I could implement this?
>>
>>--
>>Dave Cramer <Dave@micro-automation.net>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 3: if posting/reading through Usenet, please send an appropriate
>>subscribe-nomail command to majordomo@postgresql.org so that your
>>message can get through to the mailing list cleanly