Jim Nasby <jim.na...@bluetreble.com> writes:
> On 12/31/14, 8:13 AM, Andres Freund wrote:
>> Note that the C datatype has been int32/int64 for a while now, it's just
>> the SQL datatype and the names of its support functions. Given that,
>> afaiu, we're talking about the C datatype it seems pretty clear that it
>> should be named int128.
I don't think there was any debate about calling the C typedef int128.
The question at hand was that there are some existing C functions whose
names follow the int2/int4/int8 convention, and it's not very clear what
to do with their 128-bit analogues. Having said that, I'm fine with
switching to int128 for the C names of the new functions; but it is
definitely less than consistent with what we're doing elsewhere.
> Should we start down this road with SQL too, by creating int32, 64 and 128
> (if needed?), and changing docs as needed?
No. The situation is messy enough without changing our conventions at
the SQL level; that will introduce breakage into user applications,
for no very good reason because we've never had any inconsistency there.
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. 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
