| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Pg Patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: relscan.h split |
| Date: | 2008-06-15 00:48:51 |
| Message-ID: | 3678.1213490931@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Also, it seemed like some of those .c files had no business poking into
>> the scan structs anyway; particularly contrib. Did you check whether
>> the inclusions could be avoided?
> Not really, unless we were to provide something a routine that returns
> the current block of a scan.
Current buffer you mean. That wouldn't be a bad idea --- the wart I
added to genam.c the other day to recheck the current tuple could be
replaced with that, I think, though it wouldn't really be much less
warty.
BTW I think your change in pgstattuple.c is probably dangerous: if the
relation gets extended between where heap_beginscan_strat sets
rs_nblocks and where you put RelationGetNumberOfBlocks, I think the
block counting will get messed up. That one really does need access
to the internals.
Other than that, this looks pretty sane to me.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-06-15 03:09:30 | Re: [HACKERS] SSL configure patch |
| Previous Message | Alvaro Herrera | 2008-06-14 23:49:01 | Re: relscan.h split |