Re: PG_RETURN_?

Martijn van Oosterhout wrote:
> On Tue, May 02, 2006 at 08:43:03AM -0700, 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...
>
> You should always *always* match the PG_RETURN_* to the declared type
> you are returning. anything else will cause problems. PG_RETURN_INT16
> means "return in a format consistant with a type declared as
> pass-by-value two byte width". PostgreSQL does not check that what
> you're returning actually matches what you declared.

Yes, but that wasn't the question.

I can PG_RETURN_CHAR(2), PG_RETURN_INT16(2) or PG_RETURN_INT32(2)
and end up with the same result (assuming the function is defined
to return char, int2 or int4, respectively in the SQL interface).

> The type as declared determines the storage required to store it. That

Yes, but for a function returning a value that does not exceed
sizeof(Datum), there is no *space* consequence.  I would assume
most modern architectures use 32 bit (and larger) registers.

OTOH, some machines incur a (tiny) penalty for casting char to long.
Returning INT32 *may* be better from that standpoint -- assuming
there is no added offsetting cost marshalling.

> might be a far more useful factor to consider than what it copied
> internally which, as has been pointed out, is probably below what you
> can measure.

Sure.  But, given that the difference ONLY amounts to whether
I type "INT32" or "INT16" or "CHAR" in the PG_RETURN_ macro,
an understanding of what is going on "inside" can contribute
epsilon for or against performance.  I'd be annoyed to have
built dozens of functions ASSUMING "INT32" when a *better*
assumption might have been "CHAR"...  (I'm working in an
embedded environment where "spare CPU cycles" mean you've
wasted $$$ on hardware that you don't need  :-/ )

--don