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
