Re: int4 or int32
От | Tom Lane |
---|---|
Тема | Re: int4 or int32 |
Дата | |
Msg-id | 27032.974349527@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | int4 or int32 (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: int4 or int32
Re: int4 or int32 |
Список | pgsql-hackers |
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 :-( regards, tom lane
В списке pgsql-hackers по дате отправления: