Tom Lane wrote:
> Andrew Chernow <ac@esilo.com> 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
