Re: actualised funcs typmod patch - Mailing list pgsql-hackers

Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2009/11/17 Tom Lane <tgl@sss.pgh.pa.us>:
>> If the only immediate benefit we'd get is multiple anyelement types,
>> I think we'd be much better advised to just create a few separate
>> types for that. Function typmods are a big can of worms and we should
>> not lock ourselves into a half-baked solution.

> When I started work on typmod support, my motivation was only a
> multiple anyelement types. Now, I thing, so typmodes are more
> important than parametrized polymorphic type. Now, PL are dynamic with
> minimal static checks. Step by step the static checks are richer. I
> could to imagine future warning like "declared varchar(40), but
> potential content is varchar(50)". These controls are not possible
> without using typmodes in function (explicitly declared).

Yeah, there are some potential advantages, but that's all the more
reason not to jump into it on the basis of a patch that was cranked
out in a few days with no design discussion.

Aside from the point I already made about needing non-constant output
typmods, I would want to see some serious discussion about exactly how
typmods fit into function signatures in the first place.  Are
f(numeric(2)) and f(numeric(3)) distinct signatures (ie, can you have
both of these functions at the same time)?  If so, what are the
overloading resolution rules that will let us figure out which one to
call?  If not, doesn't that put a rather serious crimp in the idea that
anyelement(0) and anyelement(1) can be used in the desired fashion?

For that matter, given f(numeric(2)), does an actual argument that
is numeric with some other typmod match it at all?  We generally avoid
setting up implicit coercions that are likely or certain to fail, so
you could argue that an actual argument that's numeric(100) should not
be thought to be implicitly coercible to numeric(2).  Again though
the degree of sanity of such things seems pretty type-specific ...
do we need per-type functions to determine coercibility of typmods?
How about a case like bigint -> numeric(2), is that supposed to be
implicitly coercible?  The reason these are issues now is that before
this patch there was never a case of wanting an implicit coercion to
a specific typmod --- only explicit or assignment coercions could
have a target typmod other than -1.  I am not sure that our API for
type coercion functions can even handle the case cleanly.

There are other issues but these are the ones I think we'd need to
resolve before not after putting in function typmods.  It'd be
extremely painful and non-backwards-compatible to change our minds
later about function identity or coercion rules.
        regards, tom lane