Fix realfailN lexer rules to not make assumptions about input format.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 13 Nov 2018 19:54:41 +0000 (14:54 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 13 Nov 2018 19:54:41 +0000 (14:54 -0500)
commit965a3d6be0702fa88c6eaa6946fa86218704c7d2
tree9be9464bd73928945739a86f32d74c30b0c2d0e9
parent4766bcd9e292befba403619c8a57b3528ad3bd4b
Fix realfailN lexer rules to not make assumptions about input format.

The realfail1 and realfail2 backup-prevention rules always returned
token type FCONST, ignoring the possibility that what we've scanned
is more appropriately described as ICONST.  I think that at the
time that code was added, it might actually have been safe to not
distinguish; but since we started allowing AS-less aliases in SELECT
target lists, it's definitely legal to have a number immediately
followed by an identifier.

In the SELECT case, it seems there's no visible consequence because
make_const() will change the type back to integer anyway.  But I'm
worried that there are other contexts, or will be in future, where
it's more important to get the constant's type right.

Hence, use process_integer_literal to correctly determine which
token type to return.

Arguably this is a bug fix, but given the lack of evidence of
user-visible problems, I'll refrain from back-patching.

Discussion: https://postgr.es/m/21364.1542136808@sss.pgh.pa.us
src/backend/parser/scan.l
src/fe_utils/psqlscan.l
src/interfaces/ecpg/preproc/pgc.l