From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Adding a typmod field to Const et al |
Date: | 2007-03-16 23:07:33 |
Message-ID: | 24698.1174086453@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-03-17 00:39:24 | Re: Adding a typmod field to Const et al |
Previous Message | Andrew Dunstan | 2007-03-16 22:10:16 | Re: Buildfarm feature request: some way to track/classify failures |