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
Subject: Re: [HACKERS] CREATE FUNCTION broken
Date: 1998-02-13 15:34:51
Message-ID: m0y3N8f-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.
>
> Ah. I broke it (though the regression tests did not find the problem). What
> I changed was the code in gram.y, which used to just create a string node
> for the return type clause _unless_ the return type was a "SETOF type". In
> that case a Typename node was created, and the setof attribute was
> explicitly set.
>
> What you found is that farther along, the setof attribute was forced to be
> true if _any_ Typename node is present.

Haven't spend time to analyze if other places might have been
affected by that - just thought we should trust the parser
about the SETOF flag in TypeName node instead of knowing it
better deep down in the utility commands.

;-)

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

Small test case - hmmm.

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.

Anyway - add a little function in regress.c returning a
basetype value. Then add tests that use it in SELECT queries.

int32
allways_one()
{
return 1;
}

SELECT allways_one() AS one;

SELECT a, allways_one() AS one FROM t;

>
> Unless there are objections from others (with a preference for reverting
> the gram.y code) I'll go ahead and apply Jan's patch.

Even if reverting the gram.y code - my patch could only make
things better.

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:08:45 v6.3 release ToDo list and supported ports
Previous Message Thomas G. Lockhart 1998-02-13 15:33:36 Re: [HACKERS] postgres initdb on ALPHA/Digital Unix