I looked into the issue reported in bug #14448,
https://www.postgresql.org/message-id/20161205143037.4377.60754%40wrigleys.postgresql.org
The core of it seems to be that expandRTE() will report the type and
typmod of a column of a VALUES construct as being exprType() and
exprTypmod() of the corresponding expression in the first row of
the VALUES. It's okay to handle data type that way, because we've
coerced all the expressions for the column to the same type; but
we have *not* coerced them to the same typmod. So some of the values
from later rows may fail to meet the claimed typmod. This is not good.
In order to fix this, we first have to decide what the semantics ought
to be. I think there are two plausible definitions:
1. If all the expressions in the VALUES column share the same typmod,
use that typmod, else use -1.
2. Use -1 whenever there is more than one VALUES row.
#1 is what we do for some comparable cases such as UNION and CASE.
However, it's potentially quite expensive for large VALUES constructs.
#2 would be a lot cheaper, and given that this is the first complaint
we've gotten in all the years we've had multi-row-VALUES support, it's
not clear that deriving a precise typmod is really all that useful
for VALUES.
I have no strong preference between these two, but I think whatever
we do needs to be back-patched. The behavior described in the bug
report is definitely broken.
Thoughts?
regards, tom lane
