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

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

>  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().

- Heikki




pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Final Patch for GROUPING SETS
Next
From: Tom Lane
Date:
Subject: Re: Using 128-bit integers for sum, avg and statistics aggregates