Re: RFC for adding typmods to functions

>
> 4.  What about functions whose output typmod should depend on the input
> typmod(s)?  I mentioned earlier the example that concatenation of
> varchar(M) and varchar(N) should produce varchar(M+N).  We could possibly
> punt on this for the time being; supporting only fixed output typmods for
> now doesn't obviously foreclose us from adding support for computed
> typmods later.  However there is still one nasty case that we cannot
> push off till later: given a function that takes and returns a polymorphic
> type such as anyelement, and an actual argument with a typmod (eg
> numeric(2)), is the result numeric(2) or just numeric?  As things stand
> we would have little choice but to say the latter, because we don't know
> what the function might do with the value, and there are too many real
> cases where the result might not have the same typmod.  But there are
> also a lot of cases where you *would* wish that it has the same typmod,
> and this patch raises the stakes for throwing away typmods mid-expression.
> Is this okay, and if not what could we do about it?

polymorphic functions should to ignore typmnod :( - with current
syntax - on output. I don't believe so we are able to find any
mechanism usable for non typmod types and typmod types. We could to
enhance syntax for using typmod from parameters - maybe some flag like
STRICT, maybe TYPMOD?

Regards
Pavel

>
> Unless we have consensus on all of these points I don't think we should
> proceed with the patch.  Comments?
>
>                        regards, tom lane
>