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