Re: relscan.h split
Tom Lane <[email protected]>
| Newsgroups | gmane.comp.db.postgresql.devel.patches |
|---|---|
| Message-ID | <[email protected]> |
Alvaro Herrera <[email protected]> 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 -- Sent via pgsql-patches mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches