Good point and I loved the way you put it. More low level stuff I need to learn.
I'm still struggling trying to find the list of data type oids either in the documentation or in the postgresql source code so that I can specify the data correctly (assuming, of course, I make sure the binary on both sides is compatible.
As a general rule one wants to use the format the data is being stored in. every time data is cast to another type its going to eat those all so precious CPU cycles. (all the horror of electrons turned into infrared beams)
converting Bytea type to a string encoded in Base64 adds 30% overhead. converting an integer tor ASCII can add allot of overhead.
The answer is it depends on the USE CASE if casting adds any benefit. my gut tells me it will not add any benefiet
Paula> I'm just trying to understand the trade-offs between sending Paula> everything always as text, all integer parameters as binary, Paula> floats as binary, etc.
For passing data from client to server, there's no particular reason not to use the binary format for any data type that you understand (and where you're passing the data type oid explicitly in the query, rather than just leaving it as unknown).
For results, things are harder, because libpq is currently all-or-nothing about result type formats, and if you start using extension types then not all of them even _have_ a binary format. And to decode a binary result you need to know the type, and have code to handle every specific type's binary format.
