Re: actualised funcs typmod patch

Hello

actualised version: enhance check inside sql function

Regards
Pavel Stehule

Pavel Stehule escribió:
> Hello
>
> actualised version: enhance check inside sql function

What is this against? It has a few suspicious chunks, such as

***************
*** 358,364 ****

funcexpr->funcid = funcid;
funcexpr->funcresulttype = rettype;
! funcexpr->funcresulttypmod = -1; // TODO STEHULE
funcexpr->funcretset = retset;
funcexpr->funcformat = COERCE_EXPLICIT_CALL;
funcexpr->args = fargs;
--- 365,371 ----

funcexpr->funcid = funcid;
funcexpr->funcresulttype = rettype;
! funcexpr->funcresulttypmod = rettypmod;
funcexpr->funcretset = retset;
funcexpr->funcformat = COERCE_EXPLICIT_CALL;
funcexpr->args = fargs;

This ended up in ./src/backend/parser/parse_func.c.rej

There are other rejects and I'm not sure if I should fix them (at least
the first couple look trivial, though it's against a bunch of code
that last changed in Aug. last year) or ask for a better version ...

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Hello

I am sorry. I'll send a actualised version today.

Pavel

2009/11/13 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Pavel Stehule escribió:
>> Hello
>>
>> actualised version: enhance check inside sql function
>
> What is this against?  It has a few suspicious chunks, such as
>
> ***************
> *** 358,364 ****
>
>                funcexpr->funcid = funcid;
>                funcexpr->funcresulttype = rettype;
> !               funcexpr->funcresulttypmod = -1;  // TODO STEHULE
>                funcexpr->funcretset = retset;
>                funcexpr->funcformat = COERCE_EXPLICIT_CALL;
>                funcexpr->args = fargs;
> --- 365,371 ----
>
>                funcexpr->funcid = funcid;
>                funcexpr->funcresulttype = rettype;
> !               funcexpr->funcresulttypmod = rettypmod;
>                funcexpr->funcretset = retset;
>                funcexpr->funcformat = COERCE_EXPLICIT_CALL;
>                funcexpr->args = fargs;
>
>
>
> This ended up in ./src/backend/parser/parse_func.c.rej
>
> There are other rejects and I'm not sure if I should fix them (at least
> the first couple look trivial, though it's against a bunch of code
> that last changed in Aug. last year) or ask for a better version ...
>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

Hello

I am sending actualised patch. Sorry - I am late, I am ill.

Regards
Pavel Stehule

2009/11/13 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Pavel Stehule escribió:
>> Hello
>>
>> actualised version: enhance check inside sql function
>
> What is this against?  It has a few suspicious chunks, such as
>
> ***************
> *** 358,364 ****
>
>                funcexpr->funcid = funcid;
>                funcexpr->funcresulttype = rettype;
> !               funcexpr->funcresulttypmod = -1;  // TODO STEHULE
>                funcexpr->funcretset = retset;
>                funcexpr->funcformat = COERCE_EXPLICIT_CALL;
>                funcexpr->args = fargs;
> --- 365,371 ----
>
>                funcexpr->funcid = funcid;
>                funcexpr->funcresulttype = rettype;
> !               funcexpr->funcresulttypmod = rettypmod;
>                funcexpr->funcretset = retset;
>                funcexpr->funcformat = COERCE_EXPLICIT_CALL;
>                funcexpr->args = fargs;
>
>
>
> This ended up in ./src/backend/parser/parse_func.c.rej
>
> There are other rejects and I'm not sure if I should fix them (at least
> the first couple look trivial, though it's against a bunch of code
> that last changed in Aug. last year) or ask for a better version ...
>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

Hi,

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> I am sending actualised patch.

I've volunteered to review this patch, and before getting to read code
and documentation, then to test it, I have some more general question.

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?

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?

Regards,
--
dim

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.

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

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
>

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

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?

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.

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.

regards, tom lane

2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> 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.

My point is that if we release 8.5 with these semantics (which as far
as I can tell were not designed, but just fell out of what made for the
shortest patch) then we'll be stuck with them thereafter.

regards, tom lane

2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> 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.
>
> My point is that if we release 8.5 with these semantics (which as far
> as I can tell were not designed, but just fell out of what made for the
> shortest patch) then we'll be stuck with them thereafter.

We could to talk about it now. We are not hurry. But I would to see
some progress in this area in next two months. This patch is simple
and doesn't create any new rules or doesn't change behave. Simply
store explicitly defined typmod and use it. Nothing more. If you
thing, so this is poor or problematic - please, show samples and use
cases.

Best regards
Pavel Stehule

>
>                        regards, tom lane
>

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> My point is that if we release 8.5 with these semantics (which as far
>> as I can tell were not designed, but just fell out of what made for the
>> shortest patch) then we'll be stuck with them thereafter.

> We could to talk about it now. We are not hurry. But I would to see
> some progress in this area in next two months. This patch is simple
> and doesn't create any new rules or doesn't change behave.

What do you mean it doesn't change the behavior? It establishes a
specific set of behaviors for functions with non-default typmods in
their arguments. If we just apply whatever was the easiest thing to
implement, without any discussion, we are very likely to regret it
later.

It might be that what you've done is all fine, but I'd like some
discussion and consensus on the issues. Submitting an entirely
documentation-free patch is not the way to establish consensus.

regards, tom lane

2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> 2009/11/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> My point is that if we release 8.5 with these semantics (which as far
>>> as I can tell were not designed, but just fell out of what made for the
>>> shortest patch) then we'll be stuck with them thereafter.
>
>> We could to talk about it now. We are not hurry. But I would to see
>> some progress in this area in next two months. This patch is simple
>> and doesn't create any new rules or doesn't change behave.
>
> What do you mean it doesn't change the behavior?  It establishes a
> specific set of behaviors for functions with non-default typmods in
> their arguments.  If we just apply whatever was the easiest thing to
> implement, without any discussion, we are very likely to regret it
> later.

sorry, it's problem in my english - too simply language. This cannot
change an behave of older applications. Sure - if somebody use
explicit typmod in CREATE FUNCTION statement, then he get different
behave. But he have to do it explicitly in 8.5. It is only main
opinion - I thing, so nobody can expect surprise. In plpgsql the
behave is practically same. The difference is one - neighbourhood has
more informations about function interface.

one positive point. It fixes one small bug:

postgres=# create or replace function foo(a varchar(3))
returns varchar as $$
begin
a := 'abcdef';
return a;
end;
$$ language plpgsql;
CREATE FUNCTION
postgres=# select foo('omega');
foo
────────
abcdef
(1 row)

>
> It might be that what you've done is all fine, but I'd like some
> discussion and consensus on the issues.  Submitting an entirely
> documentation-free patch is not the way to establish consensus.
>

yes, I am sorry. I hope, so there will be some people who help with
creating documentation. What I know, it's need:

* drop notices about dropping typmod in CREATE FUNCTION statement
* enhancing documentation about pg_proc
* add note to ALTER FUNCTION about impossibility to change typmod -
the reason is same like impossibility to change defaults or names.

The new behave should be transparent for user.

Regards
Pavel Stehule
>                        regards, tom lane
>

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

> sorry, it's problem in my english

In hopes that it may help overcome the language barrier if someone
restates the issue in different words, I'll echo Tom's concerns, which
I share.

> This cannot change an behave of older applications.

Agreed. That's not the problem.

> if somebody use explicit typmod in CREATE FUNCTION statement, then
> he get different behave. But he have to do it explicitly in 8.5.

The problem here is that we are then committed to supporting that
behavior forever. There are many different options for what behavior
could and should be supported for this syntax, and we don't want to
get locked in to one of those options by happenstance. We want the
options to be discussed by the community prior to getting locked in to
something. It would be unusual for one individual to pick a direction
for something like this and to come up with a decision which is as
good, in the long run, as consensus coming out of the synergy of group
discussion could generate.

-Kevin

2009/11/17 Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>> sorry, it's problem in my english
>
> In hopes that it may help overcome the language barrier if someone
> restates the issue in different words, I'll echo Tom's concerns, which
> I share.
>
>> This cannot change an behave of older applications.
>
> Agreed.  That's not the problem.
>
>> if somebody use explicit typmod in CREATE FUNCTION statement, then
>> he get different behave. But he have to do it explicitly in 8.5.
>
> The problem here is that we are then committed to supporting that
> behavior forever.  There are many different options for what behavior
> could and should be supported for this syntax, and we don't want to
> get locked in to one of those options by happenstance.  We want the
> options to be discussed by the community prior to getting locked in to
> something.  It would be unusual for one individual to pick a direction
> for something like this and to come up with a decision which is as
> good, in the long run, as consensus coming out of the synergy of group
> discussion could generate.

I understand it well and I invite any discussion about this topic
(additing typmod to function's interface). So please, check it, test
it, write notes.

Pavel

>
> -Kevin
>

Le 17 nov. 2009 à 20:33, Tom Lane a écrit :
>> We could to talk about it now. We are not hurry. But I would to see
>> some progress in this area in next two months. This patch is simple
>> and doesn't create any new rules or doesn't change behave.
>
> What do you mean it doesn't change the behavior? It establishes a
> specific set of behaviors for functions with non-default typmods in
> their arguments. If we just apply whatever was the easiest thing to
> implement, without any discussion, we are very likely to regret it
> later.
>
> It might be that what you've done is all fine, but I'd like some
> discussion and consensus on the issues. Submitting an entirely
> documentation-free patch is not the way to establish consensus.

I'll try to help there, it's not really a review any more, but still it seems needed. Here's what I gather the specs of Pavel's work are by quick-reading through his patch:

/*
+ * Don't allow change of input typmodes. Any change should break
+ * stored casts in prepared plans.
+ */

The return type now can have a non -1 typmod given.

[implementation details of parameterTypmodes and allParameterTypmodes left out, not well understood yet, does seem to be details rather than spec level things]

+ if (rettypmod != resttypmod && rettypmod != -1)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
+ errmsg("return type mismatch in function declared to return %s",
+ format_type_with_typemod(rettype, rettypmod)),
+ errdetail("Actual return type is %s.",
+ format_type_with_typemod(restype, resttypmod))));

So you need to return a decorated value I guess, or assign it to a retval which is of the right type, including typmod. Declaring a retval text to handle a RETURNS varchar(15) won't do it.

+ /* when typmodes are different, then foerce coercion too */
+ force_coerce = declared_typmod != -1 && declared_typmod != actual_typmod;

So if you declare typmods they are NOT part of the polymorphism (also per comment upthread) but you cannot change them and there's automatic coercion when only the typmod mismatches. I think that's what Tom wanted to avoid doing (because it breaks existing code assumptions and typmod coercion is not well defined).

Here are some tests showing either the coercion of the argument (and failures to do it) or the return type typmod invalidity:
+ ERROR: cannot change parameter typmod of existing function

+ select typmodtest('a','bbbb'); -- outside plpgsql
+ ERROR: value too long for type character varying(3)

+ select typmodtest('aaaa','bbb'); -- return value
+ ERROR: value too long for type character varying(6)
+ CONTEXT: PL/pgSQL function "typmodtest" while casting return value to function's return type

Then a great deal of changes that makes me cry in favor of having something human friendly around internal catalogs representation, all this BKI stuff IIUC.

So the bulk of it is supporting return typemod declaration. This expands to OUT types, which can be cool:

+ create or replace function typmodtest(out a numeric(5,2),out b numeric(5,2), out c numeric(5,2))

Hope this helps,
--
dim

PS: about the more than one anyelement type support in functions, I'd rather have a nice SQLish syntax around it. My proposal was sth like this:

CREATE FUNCTION foo(a anyelement x, b anyelement x, c anyelement y)
RETURNS anyelement y[]
AS $$
...
$$;

2009/11/17 Dimitri Fontaine <dfontaine(at)hi-media(dot)com>:
> Le 17 nov. 2009 à 20:33, Tom Lane a écrit :
>>> We could to talk about it now. We are not hurry. But I would to see
>>> some progress in this area in next two months. This patch is simple
>>> and doesn't create any new rules or doesn't change behave.
>>
>> What do you mean it doesn't change the behavior?  It establishes a
>> specific set of behaviors for functions with non-default typmods in
>> their arguments.  If we just apply whatever was the easiest thing to
>> implement, without any discussion, we are very likely to regret it
>> later.
>>
>> It might be that what you've done is all fine, but I'd like some
>> discussion and consensus on the issues.  Submitting an entirely
>> documentation-free patch is not the way to establish consensus.
>
> I'll try to help there, it's not really a review any more, but still it seems needed. Here's what I gather the specs of Pavel's work are by quick-reading through his patch:
>
>                /*
> +                * Don't allow change of input typmodes. Any change should break
> +                * stored casts in prepared plans.
> +                */
>
> The return type now can have a non -1 typmod given.
>
> [implementation details of parameterTypmodes and allParameterTypmodes left out, not well understood yet, does seem to be details rather than spec level things]
>
> +               if (rettypmod != resttypmod && rettypmod != -1)
> +                       ereport(ERROR,
> +                                       (errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
> +                        errmsg("return type mismatch in function declared to return %s",
> +                                       format_type_with_typemod(rettype, rettypmod)),
> +                                        errdetail("Actual return type is %s.",
> +                                                          format_type_with_typemod(restype, resttypmod))));
>
> So you need to return a decorated value I guess, or assign it to a retval which is of the right type, including typmod. Declaring a retval text to handle a RETURNS varchar(15) won't do it.
>
>
> +               /* when typmodes are different, then foerce coercion too */
> +               force_coerce = declared_typmod != -1 && declared_typmod != actual_typmod;
>
> So if you declare typmods they are NOT part of the polymorphism (also per comment upthread) but you cannot change them and there's automatic coercion when only the typmod mismatches. I think that's what Tom wanted to avoid doing (because it breaks existing code assumptions and typmod coercion is not well defined).
>
> Here are some tests showing either the coercion of the argument (and failures to do it) or the return type typmod invalidity:
> + ERROR:  cannot change parameter typmod of existing function
>
> + select typmodtest('a','bbbb');   -- outside plpgsql
> + ERROR:  value too long for type character varying(3)
>
> + select typmodtest('aaaa','bbb'); -- return value
> + ERROR:  value too long for type character varying(6)
> + CONTEXT:  PL/pgSQL function "typmodtest" while casting return value to function's return type
>
>
> Then a great deal of changes that makes me cry in favor of having something human friendly around internal catalogs representation, all this BKI stuff IIUC.
>
> So the bulk of it is supporting return typemod declaration. This expands to OUT types, which can be cool:
>
> + create or replace function typmodtest(out a numeric(5,2),out b numeric(5,2), out c numeric(5,2))
>
>
> Hope this helps,

Thank you very much

> --
> dim
>
> PS: about the more than one anyelement type support in functions, I'd rather have a nice SQLish syntax around it. My proposal was sth like this:
>
> CREATE FUNCTION foo(a anyelement x, b anyelement x, c anyelement y)
>  RETURNS anyelement y[]
> AS $$
> ...
> $$;

I would to wait with discussion about syntax. I am expecting similar
battle like about named parameters and I thing, so this can wait. But
I am sure, so We return to this and others ideas.

Regards
Pavel