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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
