diff options
Diffstat (limited to 'doc/TODO.detail/function')
| -rw-r--r-- | doc/TODO.detail/function | 86 |
1 files changed, 86 insertions, 0 deletions
diff --git a/doc/TODO.detail/function b/doc/TODO.detail/function index d65928b98f..d10a75a6f5 100644 --- a/doc/TODO.detail/function +++ b/doc/TODO.detail/function @@ -528,3 +528,89 @@ Jan ************ +From owner-pgsql-hackers@hub.org Thu Sep 23 11:01:06 1999 +Received: from renoir.op.net (root@renoir.op.net [209.152.193.4]) + by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA16162 + for <maillist@candle.pha.pa.us>; Thu, 23 Sep 1999 11:01:04 -0400 (EDT) +Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id KAA28544 for <maillist@candle.pha.pa.us>; Thu, 23 Sep 1999 10:45:54 -0400 (EDT) +Received: from hub.org (hub.org [216.126.84.1]) + by hub.org (8.9.3/8.9.3) with ESMTP id KAA52943; + Thu, 23 Sep 1999 10:20:51 -0400 (EDT) + (envelope-from owner-pgsql-hackers@hub.org) +Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Thu, 23 Sep 1999 10:19:58 +0000 (EDT) +Received: (from majordom@localhost) + by hub.org (8.9.3/8.9.3) id KAA52472 + for pgsql-hackers-outgoing; Thu, 23 Sep 1999 10:19:03 -0400 (EDT) + (envelope-from owner-pgsql-hackers@postgreSQL.org) +Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) + by hub.org (8.9.3/8.9.3) with ESMTP id KAA52431 + for <pgsql-hackers@postgresql.org>; Thu, 23 Sep 1999 10:18:47 -0400 (EDT) + (envelope-from tgl@sss.pgh.pa.us) +Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) + by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13253; + Thu, 23 Sep 1999 10:18:02 -0400 (EDT) +To: wieck@debis.com (Jan Wieck) +cc: pgsql-hackers@postgreSQL.org +Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions +In-reply-to: Your message of Thu, 23 Sep 1999 03:19:39 +0200 (MET DST) + <m11TxXw-0003kLC@orion.SAPserv.Hamburg.dsh.de> +Date: Thu, 23 Sep 1999 10:18:01 -0400 +Message-ID: <13251.938096281@sss.pgh.pa.us> +From: Tom Lane <tgl@sss.pgh.pa.us> +Sender: owner-pgsql-hackers@postgreSQL.org +Precedence: bulk +Status: RO + +wieck@debis.com (Jan Wieck) writes: +> Tom Lane wrote: +>> What I am wondering, though, is whether this addition is actually +>> necessary, or is it a bug that the functions aren't run to completion +>> in the first place? + +> I've said some time (maybe too long) ago, that SQL functions +> returning tuple sets are broken in general. + +Indeed they are. Try this on for size (using the regression database): + + SELECT p.name, p.hobbies.equipment.name FROM person p; + SELECT p.hobbies.equipment.name, p.name FROM person p; + +You get different result sets!? + +The problem in this example is that ExecTargetList returns the isDone +flag from the last targetlist entry, regardless of whether there are +incomplete iterations in previous entries. More generally, the buffer +leak problem that I started with only occurs if some Iter nodes are not +run to completion --- but execQual.c has no mechanism to make sure that +they have all reached completion simultaneously. + +What we really need to make functions-returning-sets work properly is +an implementation somewhat like aggregate functions. We need to make +a list of all the Iter nodes present in a targetlist and cycle through +the values returned by each in a methodical fashion (run the rightmost +through its full cycle, then advance the next-to-rightmost one value, +run the rightmost through its cycle again, etc etc). Also there needs +to be an understanding of the hierarchy when an Iter appears in the +arguments of another Iter's function. (You cycle the upper one for +*each* set of arguments created by cycling its sub-Iters.) + +I am not particularly interested in working on this feature right now, +since AFAIK it's a Berkeleyism not found in SQL92. What I've done +is to hack ExecTargetList so that it behaves semi-sanely when there's +more than one Iter at the top level of the target list --- it still +doesn't really give the right answer, but at least it will keep +generating tuples until all the Iters are done at the same time. +It happens that that's enough to give correct answers for the examples +shown in the misc regress test. Even when it fails to generate all +the possible combinations, there will be no buffer leaks. + +So, I'm going to declare victory and go home ;-). We ought to add a +TODO item along the lines of + * Functions returning sets don't really work right +in hopes that someone will feel like tackling this someday. + + regards, tom lane + +************ + + |