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
