libpq binary transfer of the numeric data type - Mailing list pgsql-interfaces
From | Eliot Simcoe |
---|---|
Subject | libpq binary transfer of the numeric data type |
Date | |
Msg-id | 405AD008-BE30-11D8-B774-000A959CE7FA@mac.com Whole thread Raw |
Responses |
Re: libpq binary transfer of the numeric data type
Re: libpq binary transfer of the numeric data type |
List | pgsql-interfaces |
Hello Everyone, I am writing an Objective-C wrapper of libpq and would like to implement automatic type conversion between the standard PostgreSQL data types and associated Objective-C wrapper classes. it has been a struggle using the binary I/O method supported by PQexecParams() for both parameter passing and result retrieval due to the lack of documentation on the internal data representations used by PostgreSQL, and after reading a number of posts from 1999 frowning upon its usage I am aware of the issues associate with this approach. I've searched the lists numerous times for information on the binary representations of a number of types such as Date and Numeric in vain. Finally, after about a day of poking header files (literally) I was able to extract the internal data structures from the PgSQL source code. Now I am facing the challenge of deciphering their usage. typedef struct { SInt32 varlen; // variable size (std varlena header) SInt16 n_weight; // weight of 1st digit UInt16 n_sign_dscale; // sign + display scale SInt8 n_data[1]; // digits } sql_numeric; Could someone please explain to me what the varlen field is used for? It seems to hold enormous values in my testing, so it couldn't possibly be the allocated number of bytes or bits... or the number of digits stored in the n_data field. The n_data field itself is a mystery. I can't seem to figure out exactly how it is storing the digits. According to numeric.c n_data is an array of signed short integers. Each short integer represents four numbers in some sort of binary-coded-decimal like means. I can extract the values in the first two shorts, but the rest of the results seem garbled. Here is some source code illustrating what I have done: sql_numeric numeric = (sql_numeric)(*((sql_numeric *)[data bytes])); UInt16 dscale = numeric.n_sign_dscale & NUMERIC_DISPLAY_SCALE_MASK; NSMutableString *string = [NSMutableString string]; UInt32 i, c = ([data length] - 8) / 2; UInt32 partShorts = (dscale + 3) / 4; UInt32 wholeShorts = c - partShorts; for( i = 0 ; i < wholeShorts ; i++ ) { SInt16 value = (SInt16)(((SInt16 *)(numeric.n_data))[i]); char block[5]; UInt32 j = 0; char t; sprintf( block, "%d", value ); while( (t = block[j++]) != '\0' ) { [string appendFormat:@"%c", t]; } } [string appendString:@"."]; for( i = wholeShorts ; i < c ; i++ ) { SInt16 value = (SInt16)(((SInt16 *)(numeric.n_data))[i]); char block[5]; UInt32 j = 0; char t; sprintf( block, "%d", value ); while( (t = block[j++]) != '\0' ) { [string appendFormat:@"%c", t]; } } NSLog( string ); This is obviously a quick hack in a desperate attempt to figure out how the data is packed, but the results are strange. The input to the above is the numeric 123456777654.890123. The output (as displayed by NSLog()) is 123456774353.-267846, indicating that the first two shorts are decoded "correctly", but the rest is completely wrong. I am puzzled. Anyway, my first question is: How can I convert this into a double value? I know it isn't ideal, but at least it will allow the developer to access the number is some sort of meaningful way. My second question is related to an apparent difference between the documentation and one of the examples provided. Is the data always converted to big endian byte order when transferred over the network, or is it dependent on the serving architecture? It seems to me that this should be standardized, and the third example program seems to state that it is. I have read, however, posts to these lists indicating that it is not. Anyway, sorry for this long winded post, but I have been struggling for a while and would really appreciate any help anyone can give me. Thanks in advance, Eliot Simcoe Software Engineer Vantine Imaging, LLC. 315-790-1773
pgsql-interfaces by date: