| From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | functions returning sets |
| Date: | 2001-06-29 18:46:40 |
| Message-ID: | Pine.BSO.4.10.10106291258190.13871-100000@spider.pilosoft.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
I have a special RELKIND_FUNC for parser, and it seems to go through fine,
and the final query plan has 'Seq Scan on rel####', which I think is a
good sign, as the the function should pretend to be a relation.
Now, more interesting question, what's the best way to interface ExecScan
to function-executing machinery:
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-06-29 19:54:07 | Re: [GENERAL] rules on INSERT can't UPDATE new instance? |
| Previous Message | Jan Wieck | 2001-06-29 18:44:12 | Re: Configuration of statistical views |