From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using 128-bit integers for sum, avg and statistics aggregates |
Date: | 2015-01-02 22:18:53 |
Message-ID: | 25011.1420237133@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2015-01-02 22:28:35 | Re: Redesigning checkpoint_segments |
Previous Message | Heikki Linnakangas | 2015-01-02 21:58:25 | Re: Using 128-bit integers for sum, avg and statistics aggregates |