"David G. Johnston" <david.g.johnston@gmail.com> writes:
> 9.3: <1::smallint>
> 9.6: <'1'::smallint>
Oh, right, this was an intentional change awhile back. The form without
the quotes is actually an incorrect representation of the internal state:
what that produces, if you feed it back into the parser, is an int4
constant with a run-time conversion to int2. The runtime conversion will
get const-folded during planning, resulting in more or less the same
behavior; but it's nonetheless a different expression tree from the second
form, which is an int2 constant, full stop.
(digs...) It was changed in this 9.5-era commit:
commit 542320c2bd0b3796a8a9a4617cdb23fbad473390
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon Mar 30 14:59:49 2015 -0400
Be more careful about printing constants in ruleutils.c.
The previous coding in get_const_expr() tried to avoid quoting integer,
float, and numeric literals if at all possible. While that looks nice,
it means that dumped expressions might re-parse to something that's
semantically equivalent but not the exact same parsetree; for example
a FLOAT8 constant would re-parse as a NUMERIC constant with a cast to
FLOAT8. Though the result would be the same after constant-folding,
this is problematic in certain contexts. In particular, Jeff Davis
pointed out that this could cause unexpected failures in ALTER INHERIT
operations because of child tables having not-exactly-equivalent CHECK
expressions. Therefore, favor correctness over legibility and dump
such constants in quotes except in the limited cases where they'll
be interpreted as the same type even without any casting.
This results in assorted small changes in the regression test outputs,
and will affect display of user-defined views and rules similarly.
The odds of that causing problems in the field seem non-negligible;
given the lack of previous complaints, it seems best not to change
this in the back branches.
I don't see anything about this commit in the 9.5 release notes, which
perhaps is an oversight.
regards, tom lane