Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal: - Mailing list pgsql-patches

From Tom Lane
Subject Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal:
Date
Msg-id 15942.1040278357@sss.pgh.pa.us
Whole thread Raw
In response to Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal:  (Joe Conway <mail@joeconway.com>)
Responses Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal:  (Joe Conway <mail@joeconway.com>)
List pgsql-patches
Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> I'm leaning more and more to the thought that we should reconsider the
>> Berkeley approach.

> The problem with the Berkley approach is what to do if there are two SRFs in
> the target list.

Agreed.  The Berkeley code (or more accurately, the descendant code
that's in our source tree) generates the cross product of the rows
output by the SRFs, but I've never understood why that should be a good
approach to take.  I could live with just rejecting multiple SRFs in the
same targetlist --- at least till someone comes up with a convincing
semantics for such a thing.

> Is it too ugly to allow:
>    select ... from (select mysrf(foo.a, foo.b) from foo) as t;

> where the Berkley syntax is restricted to where both are true:
> 1. a single target -- the srf
> 2. in a FROM clause subselect

Point 2 doesn't mean anything I think.  Given your point 1 then the
select mysrf() ... is well-defined regardless of context.

            regards, tom lane

pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal:
Next
From: Bruce Momjian
Date:
Subject: Re: max_fsm_pages increased to 1000 by default