Don Y wrote:
Richard Huxton wrote:
Don Y wrote:
Hi,
I have a set of functions for a data type that return
small integers (i.e. [0..12]). I can, of course, represent
it as a char, short or long (CHAR, INT16 or INT32).
re there any advantages/drawbacks to chosing one particular
PG_RETURN_ type over another (realizing that they are
effectively just casts)?
If they are integers then an int would be the obvious choice. If you
are going to treat them as int2 outside the function then int2,
otherwise just integer.
Yes, I was more interested in what might be going on "behind the
scenes" inside the server that could bias my choice of WHICH
integer type to use. E.g., if arguments are marshalled as
byte arrays vs. as Datum arrays, etc. (I would suspect the
latter). Since I could use something as small as a char to
represent the values, the choice is more interested in how
OTHER things would be affected...
I must admit I've never tested, but I strongly suspect any differences
will be below the level you can accurately measure. Certainly from the
point of view of 8/16/32 bit integers I'd guess they'd all time the same
(they should all end up as a Datum). With a 64-bit CPU I'd guess that
would extend to 64 bits too. Hmm - looking at comments it seems int64 is
a reference type regardless of CPU (include/postgres.h)
> Oh, it's int2/int4 not int16/int32.
The *data type* is int2/int4 but the PG_RETURN_? macro is
PG_RETURN_INT16 or PG_RETURN_INT32 -- hence the reason
I referred to them as "CHAR, INT16 or INT32" instead of
"char, int2 or int4" :>
You're quite right. I was thinking from the other side.
--
Richard Huxton
Archonet Ltd
