Adding this comment via the CF app so it isn't lost, while an improperly-interpreted-DKIM-headers issue is still
preventingme from mailing directly to -hackers.
It was my view that the patch was getting close by the end of the last commitfest, but still contained a bit of a logic
wartmade necessary by a questionable choice of error message wording, such that in my view it would be better to
determinewhether a different error message would better conform to ISO SQL in the first place, and obviate the need for
thelogic wart.
There seemed to be some progress possible on that when petere had time to weigh in on the standard shortly after the
lastCF ended.
So, it would not have been my choice to assign RfC status before getting to a resolution on that.
Also, it is possible for a JsonbValue to hold a timestamp (as a result of a jsonpath evaluation, I don't think that can
happenany other way), and if such a jsonpath evaluation were to be the source expression of a cast to SQL timestamp,
thatsituation seems exactly analogous to the other situations being optimized here and would require only a few more
linesin the exact pattern here introduced. While that could be called out of scope when this patch's title refers to
"numericfield" specifically, it might be worth considering for completeness. The patch does, after all, handle boolean
already,as well as numeric.
