Re: [HACKERS] CREATE FUNCTION broken

From: jwieck(at)debis(dot)com (Jan Wieck)
To: lockhart(at)alumni(dot)caltech(dot)edu (Thomas G(dot) Lockhart)
Cc: jwieck(at)debis(dot)com, pgsql-hackers(at)postgresql(dot)org, vadim(at)sable(dot)krasnoyarsk(dot)su
Subject: Re: [HACKERS] CREATE FUNCTION broken
Date: 1998-02-13 16:53:44
Message-ID: m0y3OMz-000BFRC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-02-13 16:57:18 Re: [PORTS] v6.3 release ToDo list and supported ports
Previous Message Zeugswetter Andreas SARZ 1998-02-13 16:23:38 Re: [HACKERS] AIX port s_lock.h __AIX --> _AIX