Skip site navigation (1) Skip section navigation (2)

Re: binary array and record recv

From: Andrew Chernow <ac(at)esilo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com>
Subject: Re: binary array and record recv
Date: 2008-01-02 01:49:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Andrew Chernow <ac(at)esilo(dot)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.


for each record column
1. read the oid
2. read the len
3. if oid != server_oid && len!=-1
   error out, wrong data type


In response to

pgsql-hackers by date

Next:From: Gokulakannan SomasundaramDate: 2008-01-02 09:19:35
Subject: Re: Index Page Split logging
Previous:From: Simon RiggsDate: 2008-01-01 21:30:49
Subject: Re: Index Page Split logging

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group