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

[Victor Snezhko]

Shachar Shemesh <psql at shemesh.biz> writes:

>>>>+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.

  Hmm, I see now...
  I'm just a bit concerned about amount of time that it will take us to
develop some of the new schemes you proposed. All this time serious
boolean bug that leads to buffer overflow in ADO will remain unfixed
and bytea support (yes, hacky, but working) will be absent. 

>>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.

It would be good to have it. My solution works on all the applications
I use but I'm a bit uncomfortable with it.

>>>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.

-- 
WBR, Victor V. Snezhko
E-mail: snezhko at indorsoft.ru