In March of last year Tom fixed up a lot of places to reduce the places where we lose typmod info including Const structures:
> revision 1.128 > date: 2007-03-17 00:11:05 +0000; author: tgl; state: Exp; lines: +7 -6; > Fix up the remaining places where the expression node structure would lose > available information about the typmod of an expression; namely, Const, > ArrayRef, ArrayExpr, and EXPR and ARRAY SubLinks. In the ArrayExpr and > SubLink cases it wasn't really the data structure's fault, but exprTypmod() > being lazy. This seems like a good idea in view of the expected increase in > typmod usage from Teodor's work to allow user-defined types to have typmods. > In particular this responds to the concerns we had about eliminating the > special-purpose hack that exprTypmod() used to have for BPCHAR Consts. > We can now tell whether or not such a Const has been cast to a specific > length, and report or display properly if so. But the SPI api doesn't actually allow callers to get more than the typeid of the types in the result tupledesc of SPI_execute_plan: SPI_gettypeid(TupleDesc tupdesc, int fnumber) Should this function be replaced with one which allows returning a typmod as well? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
