Re: actualised funcs typmod patch

2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
>> The idea to add support for typmods in function signatures came from the
>> need to have more than one anyelement at a time in a function, and Pavel
>> proposed that we spell that anyelement(0) and anyelement(1) e.g.
>
>> Is that how we want to solve it?
>
> TBD, really.  It was one possibility.
>
>> Now, whatever the answer to that is, I guess the patch still has
>> interest in itself for being able to have a function f(x numeric(10,4))
>> for example. Right?
>
> I think there are a large number of definitional details that would have
> to be considered to determine exactly what that means or how things
> should behave, and I'm quite distressed that Pavel seems to have taken a
> code-first-think-later approach to this patch.
>
> The main stumbling block that we've run into in previous discussions is
> that it's not tremendously useful to propagate typmod unless you have
> some method for determining the appropriate *output* typmod for a
> function; and just declaring it with a fixed typmod doesn't cover
> anywhere near enough use-cases.  A simple example is that concat'ing
> varchar(20) and varchar(22) ought to yield varchar(42) --- in fact, that
> is required by SQL spec --- but there's no possible way of determining
> that without exceedingly type-specific and function-specific knowledge.
> I recall some discussion of attaching parse-time "helper" functions to
> every function that would embody such knowledge, but nobody particularly
> wanted to follow through on that.

typmod is applying on input and output too. When I working with
varchar(20) inside some custom function, then using typmod in
definition (input, result) eliminate some useless typmod conversions.
Without typmods for result - non sql functions are blackbox - no body
knows, what will be result. Without typmodes for input function cannot
trust to outside, and have to recheck input. I thing so minimally for
plpgsql programming (typmod support has a benefit), sure, only when
people use typmode based types.

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

>                        regards, tom lane
>