Re: [HACKERS] CREATE FUNCTION broken

Tom wrote:
>
> > > >     Someone changed the parser to build a TypeName node on CREATE
> > > >     FUNCTION in any  case.  As  a  side  effect,  ALL!  functions
> > > >     created  got  the  proretset  attribute  to  true. Thus for a
> > > >     SELECT the parser wrapped an Iter node around  the  Expr  and
> > > >     since  singleton  functions  set  isDone  the Iter returns no
> > > >     tuple up.
> > > It looks like your patch will completely fix things, and is better than my
> > > reverting the gram.y code. Can you suggest a small test case to include in
> > > the regression suite?
> >     The regression tests found it - but you  wouldn't  expect  it
> >     there.  It's in the trigger test, where at some places SELECT
> >     set_ttdummy(0) returns 0 columns instead of one.
>
> Ah! This might be all of the problem with the trigger regression test then? I
> had wanted Vadim to look at it because I wasn't sure what the behavior should
> be. Does this test look good to you now?

    Looks  better  now.  In  some  places  the  triggers.sql  has
    comments that an error is  expected.  And  these  errors  now
    happen :-)

    But for the different NOTICE messages I get I'm not sure too.
    Who's the one who created the trigger test's  (Vadim)?  Could
    that guy please have a look at the results now and update the
    expected/triggers.out to what's really expected?

    In addition to the triggers I get  a  failed  on  the  float8
    tests too.  The test in question is

        SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;

        ======   float8   ======
        200c200,208
        < ERROR:  pow() result is out of range
        ---
        > bad|?column?
        > ---+--------
        >    |0
        >    |NaN
        >    |NaN
        >    |NaN
        >    |NaN
        > (5 rows)
        >

    Content of table is

        QUERY: SELECT '' AS five, FLOAT8_TBL.*;
        five|f1
        ----+--------------------
            |0
            |1004.3
            |-34.84
            |1.2345678901234e+200
            |1.2345678901234e-200
        (5 rows)

    What's correct on the overflow - NaN or ERROR?

>
> >     Even if reverting the gram.y code - my patch could only  make
> >     things better.
>
> Yes, and scrappy already applied it :)
>
>                                                          - Tom
>
>


Until later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #