Re: relscan.h split

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-patches by date

  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