On Thu, Dec 19, 2013 at 8:37 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> Few observations:
> 1.
> pg_prewarm.control
> +# pg_buffercache extension
> Wrong name.
Oops.
> 2.
> +pg_prewarm(regclass, mode text default 'buffer', fork text default 'main',
> + first_block int8 default null,
> + last_block int8 default null) RETURNS int8
> {
> ..
> int64 first_block;
> int64 last_block;
> int64 nblocks;
> int64 blocks_done = 0;
> ..
> }
> is there specific reason to keep parameters type as int8, shouldn't it
> be uint32 (BlockNumber)?
There's no uint32 type at the SQL level, and int32 is no good because
it can't represent sufficiently large positive values to cover the
largest possible block number. So we have to use int64 at the SQL
level; there is precedent elsewhere. So first_block and last_block
have to be int64, because those are the raw values we got from the
user; they haven't initially been bounds-checked yet. And blocks_done
is the value we're going to return to the user, so it should match the
SQL return type of the function, which again has to be int64 because
int32 doesn't have enough range. nblocks could possibly be changed to
be BlockNumber, but I think the code is easier to understand using one
type predominantly throughout rather than worry about exactly which
type is going to be used for comparisons after promoting.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
