Re: Accidently added CONV in SQL::Statement

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/Statement/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]>