Cezary.  Your short form fix for the spurious NUMERIC CAST due to trailing
space was definitely received in your original posting.

I am interested to see your solution where NUMERIC CAST has sensible
interpretation between MAX_INT and MAX_REAL.
IMO, simple INT saturation is not convenient for easy overflow detection in
SQL.   So there is work to be done where the upcasted number is large but
not quite large enough for REAL saturation. Nearby upcasted INTs must sort
sensibly.

Also, what happens to overflowing hex constants and from BLOB casts?

It is important to curate such patches in case the priority for execution
speed/size cannot be reconciled with accuracy and generality.  If your
improvements make v3.23 slower or larger than v3.22, they may be rejected.
Nevertheless, I think users who prioritize dependability, accuracy, and
generality over slightly degraded executable speed/size will be very
interested to have your long form improvements.

Best regards.
Peter

On Thu, Jan 25, 2018 at 3:15 PM, Cezary H. Noweta <c...@poczta.onet.pl>
wrote:

> Hello,
>
> On 2018-01-25 22:58, petern wrote:
>
>> Thank you for expanding on your detailed observations.
>> If you can, please post the long patch at your customary patch site
>> http://sqlite.chncc.eu/
>>
> I was convinced that I had publicized my patch already. For the people who
> are interested in the patch, please give me a few hours to cut my new
> not-so-completely implemented functionalities from my draft version.
>
> -- best regards
>
> Cezary H. Noweta
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to