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 mich...@insulin-pumpers.org: > 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 <rehs...@gmail.com> >> 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 >>> rehs...@gmail.com >>> >>> >> >> >> -- >> Brendan Byrd <p...@resonatorsoft.org> >> Brendan Byrd <bb...@cpan.org> >> > > -- Jens Rehsack rehs...@gmail.com
