[Oledb-dev] [patch] Re: Boolean columns corruption - cause found

Shachar Shemesh psql at shemesh.biz
Sat May 6 14:32:58 UTC 2006


Victor Snezhko wrote:

>Shachar Shemesh <psql at shemesh.biz> writes:
>
>  
>
>>>Patch attached.
>>>
>>>+void GetStatus_bool( const typeinfo *_this, ATLCOLUMNINFO *colinfo, PGresult *res,
>>>+        int field_num)
>>>+{
>>>+    typeinfo::StdStat( _this, colinfo, res, field_num );
>>>+    colinfo->ulColumnSize=sizeof(VARIANT_BOOL);
>>>+}
>>> 
>>>
>>>      
>>>
>>This makes no sense. If we need this for "bool" we're going to need this
>>for each and every other type that uses "StdStat" as well.
>>    
>>
>
>No, we are need this for bool precisely because booleans are different
>in PostgreSQL and in OLE DB. PostgreSQL has 1-byte bools and OLE DB
>uses VARIANT_BOOL which is two-byte. So I don't sure if I understand
>the problem. Ints have the same length, floats too.
>  
>
Today, the value is, by default, taken from "PQfsize". To quote the manual:

> |PQfsize| returns the space allocated for this column in a database
> row, in other words the size of the server's internal representation
> of the data type. (Accordingly, it is not really very useful to
> clients.) A negative value indicates the data type is variable-length.
>
> ||

There is nothing BOOL specific about your status function, assuming we
know that sizeof(DBTYPE_BOOL) is 2. I simply rather not rely on this
mismatch again.

>Given my previous statement, I don't understand why we need to change
>anything at all. Unlike bytea patch (which, yes, involves a hack but
>even this hack is needed to avoid wrong behaviour of ATL templates),
>this is a reasonable solution.
>  
>
I think I may have a solution to bytea too. One that will not require a
hack. I'll have to look into it a little.

>>In any case, I would like to rely on "PQfsize" as little as
>>possible, if we can. 
>>    
>>
>
>For types that are binary compatible in psql and OLE DB why not?
>  
>
Because there is nothing that promises they will remain binary
compatible. PQfsize is not future proof.

          Shachar


More information about the Oledb-devel mailing list