>
> 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
>