> Peter Eisentraut <peter_e@gmx.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 :-(
Tom, I am wondering. If we don't change to int4/int8 internally now,
will we ever do it? The function manager change seems like the only
good time to do it, if we ever will. Basically, I am asking if we
should drop backward C compatibility for 7.1 and bite the bullet on the
change?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
