Thread

1. actualised funcs typmod patch

   Pavel Stehule <pavel.stehule@gmail.com> — 2009-11-04T15:26:01Z

   Hello
   
   actualised version: enhance check inside sql function
   
   Regards
   Pavel Stehule
   

2. Re: actualised funcs typmod patch

   Alvaro Herrera <alvherre@commandprompt.com> — 2009-11-12T23:07:53Z

   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
   
   

3. Re: actualised funcs typmod patch

   Pavel Stehule <pavel.stehule@gmail.com> — 2009-11-13T03:39:05Z

   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
   >
   
   

4. Re: actualised funcs typmod patch

   Pavel Stehule <pavel.stehule@gmail.com> — 2009-11-15T18:08:04Z

   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
   >
   

5. Re: actualised funcs typmod patch

   Dimitri Fontaine <dfontaine@hi-media.com> — 2009-11-17T11:00:14Z

   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
   
   

6. Re: actualised funcs typmod patch

   Tom Lane <tgl@sss.pgh.pa.us> — 2009-11-17T14:46:26Z

   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
   
   

7. Re: actualised funcs typmod patch

   Pavel Stehule <pavel.stehule@gmail.com> — 2009-11-17T15:17:48Z

   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
   >
   
   

8. Re: actualised funcs typmod patch

   Tom Lane <tgl@sss.pgh.pa.us> — 2009-11-17T17:50:29Z

   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
   
   

9. Re: actualised funcs typmod patch

   Pavel Stehule <pavel.stehule@gmail.com> — 2009-11-17T18:39:46Z

   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
   >
   
   

10. Re: actualised funcs typmod patch

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-11-17T18:54:08Z

    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
    
    

11. Re: actualised funcs typmod patch

    Pavel Stehule <pavel.stehule@gmail.com> — 2009-11-17T19:20:47Z

    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
    >
    
    

12. Re: actualised funcs typmod patch

    Tom Lane <tgl@sss.pgh.pa.us> — 2009-11-17T19:33:07Z

    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
    
    

13. Re: actualised funcs typmod patch

    Pavel Stehule <pavel.stehule@gmail.com> — 2009-11-17T19:51:24Z

    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
    >
    
    

14. Re: actualised funcs typmod patch

    Kevin Grittner <kevin.grittner@wicourts.gov> — 2009-11-17T20:14:20Z

    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
    
    

15. Re: actualised funcs typmod patch

    Pavel Stehule <pavel.stehule@gmail.com> — 2009-11-17T20:20:33Z

    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
    >
    
    

16. Re: actualised funcs typmod patch

    Dimitri Fontaine <dfontaine@hi-media.com> — 2009-11-17T22:53:13Z

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

17. Re: actualised funcs typmod patch

    Pavel Stehule <pavel.stehule@gmail.com> — 2009-11-18T06:11:27Z

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