Alex Pilosov <[EMAIL PROTECTED]> writes:
> Well, I'm on my way to implement what was discussed on list before.
> I am doing it the way Karel and Jan suggested: creating a
> pg_class/pg_attribute tuple[s] for a function that returns a setof.
What? You shouldn't need pg_class entries for functions unless they
return *tuples*. setof has nothing to do with that. Moreover, the
pg_class entry should be thought of as a record type independent of
the existence of any particular function returning it.
> I have a special RELKIND_FUNC for parser,
This seems totally wrong.
> Options are:
> 1) Create a special scan node type, T_FuncSeqScan and deal with it there.
> 2) Keep the T_SeqScan, explain to nodeSeqScan special logic when dealing
> with RELKIND_FUNC relations.
> (I prefer this one, but I would like a validation of it)
> 3) explain to heap_getnext special logic.
I prefer #1. #2 or #3 will imply slowing down normal execution paths
with extra clutter to deal with functions.
BTW, based on Jan's sketch, I'd say it should be more like
T_CursorSeqScan where the object being scanned is a cursor/portal.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
