> -----Original Message-----
> From: falcon-return-43-wlad=sun.com@stripped [mailto:falcon-
> return-43-wlad=sun.com@stripped] On Behalf Of Jim Starkey
> Sent: Friday, October 17, 2008 6:35 PM
> To: falcon@stripped
> Subject: MYSQL_TYPE_YEAR
> Here is the server code that handles the type:
> longlong Field_year::val_int(void)
> int tmp= (int) ptr;
> if (field_length != 4)
> tmp%=100; // Return last 2 char
> else if (tmp)
> return (longlong) tmp;
> This is easily the stupidest type I've had the displeasure to run into.
> One type, two inconsistent sets of semantics. Given the actual year of
> 2008, one will return 08, the other 2008. In either case, hower, an
> indexed search will give 2008 as a key.
It can be 108 with field_length=4 (default)
> What a mess!
> I suggest that StorageInterface::encodeRecord and ::decodeRecord do
> their own handling using the field->ptr and do a translation into/from
> normal years.
It does not seem to help the search. If we decode 108 to 2008 , the search
will still look for 108.
Yet, if we do not convert and do not use val_int, but just handle
field->ptr as Falcon int in all cases,
then nothing has to be done further.
> Jim Starkey
> President, NimbusDB, Inc.
> 978 526-1376
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: http://lists.mysql.com/falcon?unsub=1