Re: Accidently added CONV in SQL::Statement

Hi Michael,

I think I will do. Math::Base::Convert with convert for up-to-base64
seems to be fine, whatever MySQL extended - MySQL isn't a standard
I orientate myself or my software ;)

Cheers,
Jens

Am 05.02.2015 um 18:07 schrieb [email protected]:

> Take a look at Math::Base::Convert, maybe that will be helpful. It 
> handles VERY large integer numbers efficently instead of returning 
> floats, has a larger conversion set, including the missing bases Jens 
> asked about, and can be easily expanded to any base. You don't have 
> to re-invent the wheel.
> 
> Michael
> 
>> Sorry for my very late reply.
>> 
>> After I wrote the CONV function, I did take much of the code and
>> improved Math::BaseCalc with it.  Although, that patch is still stuck
>> in review ( https://github.com/kenahoo/perl-math-basecalc/pull/2).
>> 
>> So, I don't mind if the code was stripped out to use a separate module
>> for the conversions.  I agree that it's overly complex, since most of
>> these functions should really just be calls to modules or relatively
>> short subs.
>> 
>> The CONV function itself wasn't based on SQL-92, but since functions
>> like HEX/BIN/OCT were already needed, I wrote it for those.  The name
>> was based on the MySQL function.
>> 
>> On Mon, Dec 15, 2014 at 4:40 AM, Jens Rehsack <[email protected]>
>> wrote:
>> 
>>> Hi,
>>> 
>>> during review of SQL::Statement wrt. RT#100551 I realized that the
>>> introduced SQL_FUNCTION_CONV (
>>> https://github.com/perl5-dbi/SQL-Statement/blob/master/lib/SQL/State
>>> ment/Functions.pm#L454) is unnecessary over-complex.
>>> 
>>> Since I learned that silent removal of once shipped functionality is
>>> a evil - I'd like to get some suggestions. For existing
>>> implementation I miss a proper documentation of edge-cases: * How is
>>> 1.E converted to octal and why is that necessary in SQL? * Why do
>>> the alphabets lower 63 and 63+ based number differ? * If different
>>> encoding schemes are supported either, why is xnt and b85 missing
>>> and what's about plain ascii?
>>> 
>>> From my perspective - unless proper answers are given - the
>>> implementation of SQL_FUNCTION_CONV should be replaced by an easy to
>>> use wrapper around https://metacpan.org/release/Math-Base-Convert to
>>> rely on dedicated tested and approved.
>>> 
>>> I started a rough test whether it's possible to keep the existing
>>> API and run into different results for 1st chosen test
>>>        {
>>>           test   => 'conv 2->92',
>>>           sql    => "SELECT CONV('101 0100 1111 0111 0110 1011', 
>>>           2, 92)", result => [ ['HN(/'] ],
>>>        },
>>> Mike's module resulted 'HN)/' - so there seem to be more quirks in
>>> individual S::S solution.
>>> 
>>> Any comments?
>>> 
>>> Cheers
>>> --
>>> Jens Rehsack
>>> [email protected]
>>> 
>>> 
>> 
>> 
>> -- 
>> Brendan Byrd <[email protected]>
>> Brendan Byrd <[email protected]>
>> 
> 
> 

-- 
Jens Rehsack
[email protected]