Re: pg_buffercache causes assertion failure

Tom Lane wrote:
>
> Fixed; turns out to be an ancient parse-analysis bug that was causing
> the view definition to not agree with the function definition if the
> function definition included a nondefault typmod.
> 
> I wonder though why this contrib module is defining its output as
> numeric(10) --- seems like a pretty inefficient choice compared to,
> say, int8; or even int4 which is what the pg_locks view is using.
> 

I couldn't use int4 as the underlying datatype is unsigned int (not 
available as exposed Pg type). However, using int8 sounds promising (is 
int8 larger than unsigned int on 64-bit platforms?).

> And it's arguably a wrong specification anyway, since the code is doing
> nothing to enforce that precision.

Hmmm - that's right, not sure why I did that :-( just using numeric in 
the view might have been more sensible.

cheers

Mark