Thank you very much for your messages. I see, you've been kinda having a
conversation with yourself. :)
In order to get to the same level, would you mind starting a new
conversation again with the current state of your findings? Also, do not
yet make any assumptions about a possible improvement that is required to
jOOQ to fix your issue, prior to clearly communicating what your findings
are, ideally via a MVCE:
For example, I have no idea how to reproduce your issue, and I'm not even
convinced that you really found a flaw or glitch in jOOQ, you might just be
using the API wrong.
2018-04-06 20:58 GMT+02:00 Charles Henry <che...@snaplogic.com>:
> LOL, nope...I was wrong. It was not preserved.
> On Friday, April 6, 2018 at 11:18:39 AM UTC-7, Charles Henry wrote:
>> Hi folks,
>> I realize that one of the purposes of JOOQ is to ensure safe datatype
>> conversions, and this question may be flying in the face of the purpose of
>> I see that deep under the hood, say when communicating with Amazon
>> Redshift, a BigInt or INT8 is treated as a Double, and if passed a "NaN"
>> the value passed is treated as Double.NaN, which gets casted around and
>> passed into Long.valueOf, which safely converts my NaN to a 0.
>> I see no API hooks to disable this conversion. Is there anything I can
>> do to force JOOQ to keep the NaN regardless of datatype and SQL dialect?
>> Thanks folks,
> You received this message because you are subscribed to the Google Groups
> "jOOQ User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jooq-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.