> Do we want this feature? > ----------------------------------------------------- > Based on the many posts on this topic, I think the answer to this is a > resounding yes.
Definitely! > How do we want the feature to behave? > ----------------------------------------------------- > A SRF should behave similarly to any other table_ref (RangeTblEntry), > i.e. as a tuple source in a FROM clause. Currently there are three > primary kinds of RangeTblEntry: RTE_RELATION (ordinary relation), > RTE_SUBQUERY (subquery in FROM), and RTE_JOIN (join). SRF would join > this list and behave in much the same manner. Yes - I don't see any point in adhering to the SQL standard lame definition. We can just make "CALL proc()" map to "SELECT * FROM proc()" in the parser for compliance. > How do we want the feature implemented? (my proposal) > ----------------------------------------------------- > 1. Add a new table_ref node type: > - Current nodes are RangeVar, RangeSubselect, or JoinExpr > - Add new RangePortal node as a possible table_ref. The RangePortal > node will be extented from the current Portal functionality. > > 2. Add support for three modes of operation to RangePortal: > a. Repeated calls -- this is the existing API for SRF, but > implemented as a tuple source instead of as an expression. > b. Materialized results -- use a TupleStore to materialize the > result set. > c. Return query -- use current Portal functionality, fetch entire > result set. > > 3. Add support to allow the RangePortal to materialize modes 1 and 3, if > needed for a re-read. Looks cool. That's stuff outta my league tho. > 4. Add a WITH keyword to CREATE FUNCTION, allowing SRF mode to be > specified. This would default to mode a) for backward compatibility. Interesting idea. Didn't occur to me that we could specify it on a per-function level. How do Oracle and Firebird do it? What about the issue of people maybe wanting different behaviours at different times? ie. statement level, rather than function level? > 5. Ignore the current code which allows functions to return multiple > results as expressions; we can leave it there, but deprecate it with the > intention of eventual removal. What does the current 'setof' pl/pgsql business actually _do_? Chris ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html