Re: pg_class.relpages/allvisible probably shouldn't be a int4

On 2014-05-11 23:30:37 +0200, Andres Freund wrote:
> On 2014-05-11 12:24:30 -0400, Tom Lane wrote:
> > Andres Freund <andres@2ndquadrant.com> writes:
> > > On 2014-05-10 23:21:34 -0700, Peter Geoghegan wrote:
> > >> On Fri, May 9, 2014 at 1:50 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > >>> And adding a proper unsigned type doesn't sound like a small amount of work.
> > 
> > >> Perhaps not, but it's overdue. We ought to have one.
> > 
> > > Maybe. But there's so many things to decide around it that I don't think
> > > it's a good prerequisite for not showing essentially corrupted values in
> > > a supported scenario.
> > 
> > It's a lot harder than it sounds at first; see past discussions about how
> > we could shoehorn one into the numeric type hierarchy.  And think about
> > how C expressions that mix signed and unsigned inputs tend to give
> > surprising results :-(
> 
> Yea. I really don't like to take on such a major project to solve a
> minor problem.
> What I am thinking about right now is to expose a 'pg_blocknumber'
> type. That only does very basic operations and implicitly casts to
> int64. That's probably a much more handleable problem and it also might
> give us some more experience with unsigned types. Comments?

As a note towards that: e.g. pageinspect deals with blocknumbers and
uses int4 for that. That makes accessing the higher blocks really
awkward...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services