Re: xlog location arithmetic
От | Robert Haas |
---|---|
Тема | Re: xlog location arithmetic |
Дата | |
Msg-id | CA+TgmoZfK3LgCSz7D0O4r4HM4zNGrrNVftueAkTgxq-g3Jeddg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: xlog location arithmetic (Jim Nasby <jim@nasby.net>) |
Список | pgsql-hackers |
On Tue, Dec 13, 2011 at 12:48 PM, Jim Nasby <jim@nasby.net> wrote: > I've often wondered about adding uint2/4/8... I suspect it's actually pretty uncommon for people to put negative numbersinto int fields, since one of their biggest uses seems to be surrogate keys. > > I realize that this opens a can of worms with casting, but perhaps that can be kept under control by not doing any implicitcasting between int and uint... that just means that we'd have to be smart about casting from unknown, but hopefullythat's doable since we already have a similar concern with casting unknown to int2/4/8 vs numeric? I've wondered about it too, but it seems like too large a can of worms to open just to address this case. Returning the value as numeric is hardly a disaster; the user can always downcast to int8 if they really want, and as long as it's < 2^63 (which in practice it virtually always will be) it will work. It's not clear what the point of this is since for typical values numeric is going to take up less storage anyway (e.g. 1000001 is 7 bytes on disk as a numeric), not to mention that it only requires 4-byte alignment rather than 8-byte alignment, and probably no one does enough arithmetic with LSN values for any speed penalty to matter even slightly, but it should work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: