Re: actualised funcs typmod patch

2009/11/17 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.

I sent a proposal. Nobody replayed. But I invite any 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?
>

a) I take typmod of argument similarly like name. It cannot be
altered, and it isn't used as part of function's signature. These
rules are similar like argname - from same reasons. So there cannot
exists functions f(numeric(2)) and f(numeric(3)) in same time.

b) polymorphic types are other - and are differently processed - now
(and in future). anyelement(0) and enyelement(1) dosn't mean so A0 is
different than A1 (it's my idea, should be different). It's mean, so
A0 should be processed independently on A1. Basically - multiple
enyelement type hasn't any bigger benefit to current situation. We
have "any". The big limit of "any" type is hard specification of
return type. I understand why and I would to create new tool for
arounding this limit.So I can to prepare a polymorphic signature:

FUNCTION foo(A0,A0, A1, A0, A1, ...) RETURNS A1,
FUNCTION foo(IN A0, IN A1, IN A2) RETURNS table(A1, A2)

I don't see an sense of parametrized types for input, for me - the
possibility better to specify result type(s) of polymorphic functions
is important. Sure - this feature should be implemented via real
types, - maybe via domains - or via typmode. We should to have two any
views on parametrised polymorphic types: a) A0, A1 are different
types, b) A0 means use real type on first position, A1 - use real type
on second position. I am inclined to b. For b. typmod is native.

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

Look to proposed code, please. These situation are solved (if I
understand well) and tested in regress tests.


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

I am sure, so this patch cannot break any current code.

Why - current pg_dump ignore typmods in function signature - so older
code use -1 as typmod for function arguments/result everywhere, on 8.4
and older databases could not be stored typmod in pg_proc, so these
changes, cannot have impact on older code.

regards
Pavel Stehule


>                        regards, tom lane
>