On Thu, Jan 18, 2018 at 1:03 PM, Tom Lane <tgl@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