> Taking another look around ecpg to see how this interacts with C-syntax > integer literals. I'm not aware of any particular issues, but it's > understandably tricky.
I can find no discussion in the archives about the commit that added "xch":
commit 6fb3c3f78fbb2296894424f6e3183d339915eac7 Author: Michael Meskes <meskes@postgresql.org> Date: Fri Oct 15 19:02:08 1999 +0000
*** empty log message ***
...and I can't think of why bounds checking a C literal was done like this.
Regarding the patch, it looks good overall. My only suggestion would be to add a regression test for just below and just above overflow, at least for int2.
Minor nits:
- * Process {integer}. Note this will also do the right thing with {decimal}, + * Process {*integer}. Note this will also do the right thing with {numeric},
I scratched my head for a while, thinking this was Flex syntax, until I realized my brain was supposed to do shell-globbing first, at which point I could see it was referring to multiple Flex rules. I'd try to rephrase.
Also, it's not this patch's job to do it, but there are at least a half dozen places that open-code turning a hex char into a number. It might be a good easy "todo item" to unify that.
