Re: int4 or int32

> 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