| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
| Cc: | 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 21:58:25 |
| Message-ID: | 54A71481.8050609@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-01-02 22:18:53 | Re: Using 128-bit integers for sum, avg and statistics aggregates |
| Previous Message | Jim Nasby | 2015-01-02 21:55:23 | Re: Final Patch for GROUPING SETS |