Re: Using 128-bit integers for sum, avg and statistics aggregates

On 1/2/15, 4:18 PM, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas(at)vmware(dot)com> writes:
>> >On 01/02/2015 11:41 PM, Tom Lane wrote:
>>> >>What might be worth trying is establishing a hard-and-fast boundary
>>> >>between C land and SQL land, with bitwise names in C and bytewise names
>>> >>in SQL. This would mean, for example, that int4pl() would be renamed to
>>> >>int32pl() so far as the C function goes, but the function's SQL name would
>>> >>remain the same.
>> >I don't like that. I read int4pl as the function implementing plus
>> >operator for the SQL-visible int4 datatype, so int4pl makes perfect sense.
> I agree with that so far as the SQL name for the function goes, which is
> part of why I don't think we should rename anything at the SQL level.
> But right now at the C level, it's unclear how things should be named,
> and I think we don't really want a situation where the most appropriate
> name is so unclear and potentially confusing. We're surviving fine with
> "int32" in C meaning "int4" in SQL so far as the type names go, so why not
> copy that naming approach for function names?

Realistically, how many non-developers actually use the intXX SQL names? I don't think I've ever seen it; the only places I recall seeing it done are code snippets on developer blogs. Everyone else uses smallint, etc.

I know we're all gun-shy about this after standard_conforming_strings, but that affected *everyone*. I believe this change would affect very, very few users.

Also, note that I'm not talking about removing anything yet; that would come later.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com