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