Tom Lane <tgl@sss.pgh.pa.us> writes:
Stark <gsstark@mit.edu> writes:
> > Is it just me or are the send/recv strangely asymmetric?
>
> Not all that much: they both return a meaningful result. We cheated a
> little bit by allowing the recv functions to modify the state of their
> input argument, but they still deliver a valid result object.
"both return something" seems like an odd axis to measure.
In one case it's given pointer to the entire message, picks out the piece it's
interested in and advances the cursor. I would expect the complementary
function to get a pointer to the entire message, take the part it's
responsible for and stuff it into that buffer advancing the cursor.
It stands out to me because the recv api seems like it's intentionally
designed around avoiding the extra copy. Then to see the send function not
make any effort in the same direction seems odd.
What I'm pondering here is that the extra copy to construct the bytea for
every single data type being output seems like it would be a pretty big
contribution to the complaint that postgres takes too much cpu in cases that
should be entirely i/o bound.
> Anyway it's about three years too late to be debating this ;-)
I suppose. Though it doesn't seem like it would be impossible to allow both
the "easy" form that returns a bytea and the "high performance" zero-copy
form. If there was a similar "easy" form for recv then it would be more
feasible to implement data types without C programming too.
I guess that's nowhere until I figure out a way to profile all these send
functions separately though.
--
greg