Re: pg_class.relpages/allvisible probably shouldn't be a int4
От | Alvaro Herrera |
---|---|
Тема | Re: pg_class.relpages/allvisible probably shouldn't be a int4 |
Дата | |
Msg-id | 20140530141842.GP7857@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: pg_class.relpages/allvisible probably shouldn't be a int4 (Andres Freund <andres@2ndquadrant.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: