Re: SRF rescan testing - Mailing list pgsql-hackers

Joe Conway wrote:
> Tom Lane wrote:
>>
>> Now that I think about it, it's possible that ExecFunctionReScan is
>> correct now, at least given the simplistic always-materialize policy
>> that we've implemented so far.  But it hasn't gotten much testing.
> 
> OK -- the attached (stand alone) test script exercises 
> ExecFunctionReScan, including cases with chgParam != NULL. I'll try to 
> come up with one or two more variants for the latter, but so far I have 
> not found any misbehavior.

I'm thinking about next steps for SRFs and looking for input. The 
current status is that SRFs seem to work properly in the 
alway-materialize mode, for the following cases of FROM clause functions 
and VIEWs created based on FROM clause functions:

(rehash from earlier post)
Language        RetSet  RetType Status
--------------- ------- ------- ---------------------
C               t       b       OK
C               t       c       Not tested
C               f       b       OK
C               f       c       Not tested
SQL             t       b       OK
SQL             t       c       OK
SQL             f       b       OK
SQL             f       c       OK
PL/pgSQL        t       b       No retset support
PL/pgSQL        t       c       No retset support
PL/pgSQL        f       b       OK
PL/pgSQL        f       c       OK
-----------------------------------------------------
RetSet: t = function declared to return setof something
RetType: b = base type; c = composite type

I've also submitted a patch for a regression test (any feedback?). At 
this point I know of several things which need to be done (or at least I 
think they are desirable):

1. Documentation -- it wasn't clear if Joel Burton was going to have 
time to contribute something here, but if not, I'll start working on 
this next. Any guidance as to which section of the docs this should go in?

2. Create a sample C-function which returns setof a composite type 
(possibly in conjunction with #1)

3. PL/pgSQL support for returning sets -- this seems to me like an 
important item if SRFs are to be useful to the masses. Any pointers on 
how to approach this would be appreciated.

4. Non-materialize mode support for SRFs.

5. Improve the system so that lower-level plan nodes will be told 
whether they need to support rescan.

6. Support for named composite types that don't have a table tied to them.

Have I missed anything major? Is this order of priority reasonable?

Thanks,

Joe