From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_class.relpages/allvisible probably shouldn't be a int4 |
Date: | 2014-05-30 14:18:42 |
Message-ID: | 20140530141842.GP7857@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund wrote:
> On 2014-05-11 23:30:37 +0200, Andres Freund wrote:
> > 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...
Sounds like pg_blocknumber could be a good idea, but I wouldn't add the
bigint implicit casts to int64. We might enlarge BlockNumber to
unsigned 64 bits in the future -- we will regret the implicit casts to
signed int64 then. Anyway it's not like implicit casts will get us any
extra functionality. We can just add + and - operators, and that should
cover 99% of what people would initially want ...
Now, adding casts FROM int32 and int64 to pg_blocknumber doesn't sound
bad. (Maybe have them error out if the value is negative?)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2014-05-30 14:55:18 | Re: SP-GiST bug. |
Previous Message | Claudio Freire | 2014-05-30 13:36:37 | Re: Extended Prefetching using Asynchronous IO - proposal and patch |