A month or so back I wrote:
> BTW, I think a good case could be made that the core of the problem
> is exactly that struct Const doesn't carry typmod, and thus that we
> lose information about constructs like 'foo'::char(7). We should fix
> that, and also anywhere else in the expression tree structure where
> we are discarding knowledge about the typmod of a result. This has
> got some urgency because of Teodor's recent work on allowing user
> defined types to have typmods --- we can expect massive growth in the
> number of scenarios where it matters.
I looked into this and determined that the interesting cases seem to be
Const: needs a struct field added
ArrayRef: ditto; but we could drop refrestype which is
redundant
SubLink: EXPR and ARRAY cases should recurse to
subplan target item, as exprType() does
ArrayExpr: should adopt the same behavior as Coalesce and
similar nodes, ie, if all the elements show the
same type/typmod then return that typmod
instead of -1
With these changes, exprTypmod covers all the same cases as exprType,
except for cases that demonstrably don't have a typmod, such as the
result of a non-length-coercion function, or nodes that have a hardwired
result type such as BOOL that doesn't take a typmod.
Comments, objections?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
