Thread: actualised funcs typmod patch
Hello actualised version: enhance check inside sql function Regards Pavel Stehule
Attachment
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@commandprompt.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@commandprompt.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 >
Attachment
Hi, Pavel Stehule <pavel.stehule@gmail.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@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
2009/11/17 Tom Lane <tgl@sss.pgh.pa.us>: > 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. 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.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.
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@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 >
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2009/11/17 Tom Lane <tgl@sss.pgh.pa.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@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> 2009/11/17 Tom Lane <tgl@sss.pgh.pa.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.stehule@gmail.com> writes:
> 2009/11/17 Tom Lane <tgl@sss.pgh.pa.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@sss.pgh.pa.us>:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> 2009/11/17 Tom Lane <tgl@sss.pgh.pa.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.stehule@gmail.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.Grittner@wicourts.gov>: > Pavel Stehule <pavel.stehule@gmail.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'swork 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
bedetails 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.
Declaringa 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
andthere's automatic coercion when only the typmod mismatches. I think that's what Tom wanted to avoid doing (because
itbreaks 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
proposalwas 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@hi-media.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
ofPavel'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
bedetails 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
themand there's automatic coercion when only the typmod mismatches. I think that's what Tom wanted to avoid doing
(becauseit 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
proposalwas 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