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

        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

Reply via email to