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