Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal:
| От | Joe Conway |
|---|---|
| Тема | Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal: |
| Дата | |
| Msg-id | 3E0F9ED0.60404@joeconway.com обсуждение исходный текст |
| Ответ на | Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal: (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [Fwd: SETOF input parameters (was Re: [HACKERS] proposal:
|
| Список | pgsql-patches |
Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: > >>Tom Lane wrote: >> >>>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. > > >>I would like to start spending some time digging in to this. Any pointers or >>thoughts on the best way to implement it? A little direction might save me >>days of wheel spinning :-). > > > Implement what exactly? Well, I want to allow a single table function (or srf if you prefer) in the target list as discussed above. Currently, when you try it, record_out() gets called from printtup() when the srf is encountered, which generates an ERROR. The behavior in 7.2.x is to return a pointer when the composite type is output. I think that to make this work as discussed, the target list needs to be "expanded" for the composite type (similar to expanding a "*" I would think), so I was starting to look at transformTargetList() and ExpandAllTables(). > > The code that presently does the dirty work is in ExecTargetList(), if > that's what you're looking for... > OK -- i'll check that out too. Thanks, Joe
В списке pgsql-patches по дате отправления: