Re: Using 128-bit integers for sum, avg and statistics aggregates - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Using 128-bit integers for sum, avg and statistics aggregates
Date
Msg-id 20141231141345.GC19836@alap3.anarazel.de
Whole thread Raw
In response to Re: Using 128-bit integers for sum, avg and statistics aggregates  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Using 128-bit integers for sum, avg and statistics aggregates  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On 2015-01-01 03:00:50 +1300, David Rowley wrote:
> > > 2. References to int16 meaning 16 bytes. I'm really in two minds about
> > this,
> > > it's quite nice to keep the natural flow, int4, int8, int16, but I can't
> > > help think that this will confuse someone one day. I think it'll be a
> > long
> > > time before it confused anyone if we called it int128 instead, but I'm
> > not
> > > that excited about seeing it renamed either. I'd like to hear what others
> > > have to say... Is there a chance that some sql standard in the distant
> > > future will have HUGEINT and we might regret not getting the internal
> > names
> > > nailed down?
> >
> > Yeah, I think using int16 to mean 16-bytes will be confusing to
> > someone almost immediately.
> >
> >
> hmm, I think it should be changed to int128 then.  Pitty int4 was selected
> as a name instead of int32 back in the day...

Note that the C datatype has been int32/int64 for a while now, it's just
the SQL datatype and the names of its support functions. Given that,
afaiu, we're talking about the C datatype it seems pretty clear that it
should be named int128.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Additional role attributes && superuser review
Next
From: Thom Brown
Date:
Subject: Re: Parallel Seq Scan