On 2014-05-11 23:30:37 +0200, Andres Freund wrote: > On 2014-05-11 12:24:30 -0400, Tom Lane wrote: > > Andres Freund <and...@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 <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
