From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: int4 or int32 |
Date: | 2000-11-16 04:38:47 |
Message-ID: | 27032.974349527@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Which one of these should we use?
> int4 is a data type, int32 isn't. c.h has DatumGetInt8, but no
> DatumGetInt64; it also has DatumGetInt32 but no DatumGetInt4. fmgr has
> PG_GETARG_INT32 et al. Inconsistency everywhere.
The original convention was to use int4 etc at the SQL level, int32 etc
at the C level. However the typedefs int4 etc have to be visible in
the include/catalog/pg_*.h headers, and so there's been a certain amount
of leakage of those typedefs into the C sources.
I think that int32 etc are better choices at the C level because of
the well-established precedent for naming integer types after numbers
of bits in C code. I don't feel any strong urge to go around and
change the existing misusages, but if you want to, I won't object.
I also have to plead guilty to having changed all the float-datatype
code to use float4 and float8 recently. This was mainly because the
existing typedefs for float32 and float64 had a built-in assumption
that these types would always be pass-by-reference, and I wanted to
abstract the code away from that assumption. We can't touch those
typedefs for a release or three (else we'll break existing user
functions written in C), so switching to the SQL-level names seemed
like the best bet. But it's not real consistent with the integer-type
naming conventions :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-11-16 04:42:05 | Re: Coping with 'C' vs 'newC' function language namesh |
Previous Message | Tom Lane | 2000-11-16 04:28:53 | Re: termcap and curses |