| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alex Pilosov <alex(at)pilosoft(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: selecting from cursor |
| Date: | 2001-07-03 14:02:24 |
| Message-ID: | 18108.994168944@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alex Pilosov <alex(at)pilosoft(dot)com> writes:
>> And what are you doing with the places that don't care which kind of RTE
>> they are dealing with (which is most of them IIRC)? While you haven't
> They just have things declared as RangeTblEntry *, and as long as they
> don't access type-specific fields, they are fine.
So you have four (soon to be six or seven) different structs that *must*
have the same fields? I don't think that's cleaner than a union ...
at the very least, declare it as structs containing RangeTblEntry,
similar to the way the various Plan node types work (see plannodes.h).
> For scrollable cursors, Rescan should be implemented as 'scroll backwards
> until you can't scroll no more', correct?
No, it should be implemented as Rescan. The portal mechanism needs to
expose the Rescan call for the contained querytree.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-07-03 14:12:53 | Re: AW: selecting from cursor |
| Previous Message | Jean-Francois Leveque | 2001-07-03 13:59:01 | Trigger Procedures question |