Should SPI_gettypeid be extended to support returning the typmod?

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