Dent John wrote:
> I’ve made a revision of this patch.
Some comments:
* the commitfest app did not extract up the patch from the mail,
possibly because it's buried in the MIME structure of the mail
(using plain text instead of HTML messages might help with that).
The patch has no status in http://commitfest.cputube.org/
probably because of this too.
* unnest-refcursor-v3.patch needs a slight rebase because this chunk
in the Makefile fails
- regexp.o regproc.o ri_triggers.o rowtypes.o ruleutils.o \
+ refcursor.o regexp.o regproc.o ri_triggers.o rowtypes.o ruleutils.o \
* I'm under the impression that refcursor_unnest() is functionally
equivalent to a plpgsql implementation like this:
create function unnest(x refcursor) returns setof record as $$
declare
r record;
begin
loop
fetch x into r;
exit when not found;
return next r;
end loop;
end $$ language plpgsql;
but it would differ in performance, because internally a materialization step
could be avoided, but only when the other patch "Allow FunctionScans to
pipeline results" gets in?
Or are performance benefits expected right away with this patch?
*
--- a/src/backend/utils/adt/arrayfuncs.c
+++ b/src/backend/utils/adt/arrayfuncs.c
@@ -5941,7 +5941,7 @@ array_fill_internal(ArrayType *dims, ArrayType *lbs,
/*
- * UNNEST
+ * UNNEST (array)
*/
This chunk looks unnecessary?
* some user-facing doc would be needed.
* Is it good to overload "unnest" rather than choosing a specific
function name?
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite