Interesting problem comparing strings with integer values...

[Chris Spencer]

	The comparison will not be done inside of a Python interpreter, but in
an SQL statement. ie...
select blah from table where value>"999" and value<"3432";

We're storing arbitrary data in text blobs, so we can't make "value" above an
integer type.

As I mentioned in my first post, while the above SQL statement would be
incorrect, the below SQL code WOULD.

select blah from table where value>"00000999" and value<"00003432";

This just seems incredibly hack-y to me.  It means that we'd have a hardcoded
limit for padding values with zeroes.  It gets even more fun when I talk
floating point values...But one step at a time.

Note that this works as well:
select blah from table where value>"1111100111" and value<"110101101000";

However, I've not been able to find an equivalent to hex() or oct() that would
turn integers into binary string representation.  If there IS such a beastie,
please let me know.

Chris.

On Wed, 15 Jan 2003 16:02:59 -0800, you wrote:

>On Wednesday 15 January 2003 15:23, Chris Spencer wrote:
>> Due to certain design constraints, I must be able to store both
>> integers and floating point numbers as strings.  These strings must
>> be able to be compared correctly, so things like: "999"<"3432" are
>> not possible. One option we thought of was padding the strings with
>> zeros, so things like: "00000999"<"00003432" would work.  This seems
>> a bit hack-y to me.  I was wondering if anyone has a more elegant
>> solution to the problem?
>
>If you must only store the numbers as strings, then you could easily 
>convert them back to number types for comparisons, ie:
>
>float("999") < float("3432")
>
>A fancy method would be to try converting to floats, and if that fails, 
>convert to longs for comparison.  If this approach isn't workable, then 
>you need to more clearly identify your needs.  Is speed an issue?  Is 
>it really only an issue of storing data as strings, or must you operate 
>directly on those strings as well, etc.?  And will the numbers all be 
>small (floats loose precision as they get to be very large, for example)