Re: actualised funcs typmod patch

Dimitri Fontaine <dfontaine@hi-media.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.

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.
        regards, tom lane