Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
When dealing with binary, the Oid the client sends may match what the
server thinks but the data is wrong (client sent binary formatted data
of the wrong type). Thus, the only real check we saw was on the data
length (which is rolling the dice).
Yes, the available checks to detect client-vs-server datatype mismatch
are very weak, but that hardly comes across as a good argument for
removing one of the ones we have.
How is the client supposed to send back composite types without having a
meaningful way to get the Oids from the server?
On what grounds do you claim that it can't get the type Oids from the
server?
regards, tom lane
I was wondering if anyone would be opposed to a small allowance here.
When trying to send a NULL value for a record/composite column, is it
possible to simply ignore the recv'd oid? Currently, the oid of each
column is read and checked against the server. If the oids don't match,
an error is raised. I see Tom's take on this, a weak check is better
than no check at all. But when passing in a NULL value, setting length
to -1, I'm not sure this check even registers as a weak one.
Maybe:
for each record column
1. read the oid
2. read the len
3. if oid != server_oid && len!=-1
error out, wrong data type
andrew
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
