On Thu, Dec 07, 2023 at 07:40:30PM -0500, Tom Lane wrote:
> Hmm ... I think that might not be the way to think about it. What
> I'm wondering is why we need a test as expensive as IsValidJsonNumber
> in the first place, given that we know this is a numeric data type's
> output. ISTM we only need to reject "Inf"/"-Inf" and "NaN", which
> surely does not require a full parse. Skip over a sign, check for
> "I"/"N", and you're done.
>
> ... and for that matter, why does quoting of Inf/NaN require
> that we apply something as expensive as escape_json? Several other
> paths in this switch have no hesitation about assuming that they
> can just plaster double quotes around what was emitted. How is
> that safe for timestamps but not Inf/NaN?
I did both of these in v2, although I opted to test that the first
character after the optional '-' was a digit instead of testing that it was
_not_ an 'I' or 'N'. I think that should be similar performance-wise, and
maybe it's a bit more future-proof in case someone invents some new
notation for a numeric data type (/shrug). In any case, this seems to
speed up my test by another half a second or so.
I think there are some similar improvements that we can make for
JSONTYPE_BOOL and JSONTYPE_CAST, but I haven't tested them yet.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com