Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

Next:From: Dave PageDate: 2002-05-12 21:03:07
Subject: Operator Comments
Previous:From: Joel BurtonDate: 2002-05-12 19:48:35
Subject: Re: TRUNCATE

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group