Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Date: 2002-05-12 20:33:47
Message-ID: 10881.1021235627@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)com> writes:
> Here's the patch, per my post to HACKERS.
> It builds cleanly on my dev box, and passes all regression tests.

I've committed this with some revisions. The VIEW cases you were
worried about seem to work now. I think you'll find that
single-FROM-item cases generally work, and it's time to start worrying
about joins (ie, rescans).

Parameters also need thought. This should be rejected:

regression=# select * from foo, foot(fooid) z where foo.f2 = z.f2;
server closed the connection unexpectedly

On the other hand, IMHO this should work:

regression=# select * from foo where f2 in
regression-# (select f2 from foot(foo.fooid) z where z.fooid = foo.fooid);
server closed the connection unexpectedly

and here again rescanning is going to be critical.

regards, tom lane

PS: test case for above:

create table foo(fooid int, f2 int);
insert into foo values(1, 11);
insert into foo values(2, 22);
insert into foo values(1, 111);

create function foot(int) returns setof foo as '
select * from foo where fooid = $1' language sql;

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2002-05-12 21:03:07 Operator Comments
Previous Message Joel Burton 2002-05-12 19:48:35 Re: TRUNCATE

Browse pgsql-patches by date

  From Date Subject
Next Message Rod Taylor 2002-05-13 02:08:58 comment on operator / schema
Previous Message Rod Taylor 2002-05-12 17:21:00 Truncate