On Thu, Jan 18, 2018 at 1:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Sure. Part of the equation here is that (IMO anyway) int128 isn't > sufficiently performance-critical to us to justify putting enormous > amounts of work into trying to make it go on non-mainstream platforms. > It's possible that that could change in future ... but if part of the > cost is notational changes that make it harder and more bug-prone > to use int128 at all, then I daresay int128 will never become that > performance-critical, because it would always remain a niche thing.
That's possible. On the other hand, we lived for many years with painful workarounds for systems without working 64-bit integers, and those eventually became mainstream enough that we made them mandatory - and then ripped out some of the notational changes that we'd introduced to cope with platforms that didn't support them. So, the same thing might happen here, whatever we decide about this. Then again, 64 bit counters are already so large that it's hard to imagine ever having one overflow, so perhaps 128-bit values will never catch on in quite the same way. On the third hand, 640kB ought to be enough for anybody. Anyway, that's really an academic debate. My real point is: I do not think we should reject out of hand the idea that a patch introducing some new notation to deal with this might be acceptable. I am not volunteering to write such a patch, and anyone who tries should be aware that there is a chance that it will be rejected on grounds of ugliness. However, if they decide to try anyway, we should read the patch and see how ugly it really is. Maybe it's not that bad. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
