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

From Tom Lane
Subject Re: Using 128-bit integers for sum, avg and statistics aggregates
Date
Msg-id 25011.1420237133@sss.pgh.pa.us
Whole thread Raw
In response to Re: Using 128-bit integers for sum, avg and statistics aggregates  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Using 128-bit integers for sum, avg and statistics aggregates
List pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.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?

>> That would introduce visible inconsistency between such
>> functions' pg_proc.proname and pg_proc.prosrc fields, but at least the
>> inconsistency would follow a very clear pattern.  And I doubt that very
>> many user applications are depending on the contents of pg_proc.prosrc.

> Someone might be doing
> DirectFunctionCall2(int4pl, ...)
> in an extension. Well, probably not too likely for int4pl, as you could 
> just use the native C + operator, but it's not inconceivable for 
> something like int4recv().

We don't have a lot of hesitation about breaking individual function calls
in extensions, so long as (1) you'll get a compile error and (2) it's
clear how to update the code.  See for instance the multitude of cases
where we've added new arguments to existing C functions.  So I don't think
this objection holds a lot of water, especially when (as you note) there's
not that much reason to be calling most of these functions directly from C.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Using 128-bit integers for sum, avg and statistics aggregates
Next
From: Josh Berkus
Date:
Subject: Re: Redesigning checkpoint_segments