On Nov 29, 2005, at 13:28, Tom Lane wrote:
> You cannot control the FE/BE protocol from inside a user function.
"cannot" is a bit strong -- the function in my original email did it,
and it works (with caveats). It's good to know that I "should" not,
though. I'm still curious why I got the error message:
server sent data ("D" message) without prior row description
("T" message)
Is the 'T' message sent back to the client before my function was
invoked? Can the 'T' message be suppressed until immediately before
the first piece of tuple data is returned to the client? That way, I
could do my COPY operation before the 'T' message is sent and no one
would be the wiser.
>> This seems more efficient to me than passing BYTEAs back and forth.
>
> Why? A byte is a byte. There is no possible way that you will ever
> save enough microseconds from this to repay the development time you
> will waste trying to kluge the system to do it.
Does that still apply to BYTEAs that are tens (hundreds?) of
megabytes? I was hoping to stream the data so that I wouldn't have to
read it all into memory and pass it to the function (or return it
from the function) as one big chunk. That way, the first part could
be going out over the network while the function was reading in the
rest of the data. It wouldn't have to wait to read the entire piece
of data into memory before transmitting it. I could also put up a
nice little progress bar for the transfer.
If I pass in the data as a BYTEA parameter to the function, is the
data transmitted completely before the function is invoked? If the
function fails before it even needs the data (due to an invalid
argument, etc), it seems wasteful to have transmitted it across the
wire.
I also wanted to avoid the hassle of having to massage the binary
data (escaping values, etc) before transmitting it, but perhaps using
the binary format in libpq is all that's needed. Can I easily turn a
buffer of data into a BYTEA and pass it to PQexecParams()?
Thanks!
- Chris
