mirror of
https://github.com/postgres/postgres.git
synced 2025-04-24 10:47:04 +03:00
87 lines
4.1 KiB
Plaintext
87 lines
4.1 KiB
Plaintext
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
|
|
|
|
************
|
|
|
|
|