Re: More pain and sufferring with Tropashko's materialized path...

From: Mikito Harakiri <mikharakiri_at_ywho.com>
Date: Mon, 15 Sep 2003 12:04:30 -0700
Message-ID: <zbo9b.23$lB2.80_at_news.oracle.com>


My mileage is different! The fifth child of the 113755/65536 node:

select child_numer(113755,65536,5)||'/'||

     child_denom(113755,65536,5) from dual

3640131/2097152

Self test:

select parent_numer(child_numer(numer, denom,5),child_denom(numer, denom,5))||'/'||

    parent_denom(child_numer(numer, denom,5),child_denom(numer, denom,5)) from (

    select 113755 numer, 65536 denom from dual )

113755/65536

I remember Joe Celko calling names RDBMS implementation he disliked. What would Joe's comment be here?

BTW, I figured out one more labeling that is "more compact".

"Robin Tucker" <r.tucker_at_thermoteknix.com> wrote in message news:bk4v08$mek$1$8302bc10_at_news.demon.co.uk...
>
> When I execute this function with a number such as 113755/65536, I get
> arithmetic overflow. When I convert them to "real", same problem.
> Everything is fine with smaller numbers, such as you get for the test
cases
> given.
>
> This problem has occurred on a test tree containing only 500 nodes that
goes
> to a depth of 12. I thought I had this materialized path thing cracked,
but
> it seems I haven't! (using MS T-SQL by the way, perhaps there is some
other
> data-type I should be using?).
>
> Any ideas?
>
>
> ALTER FUNCTION dbo.func_Get_Child_Numerator
> (
> _at_numer INTEGER,
> _at_child INTEGER
> )
> RETURNS INTEGER
> AS
> BEGIN
> RETURN _at_numer * POWER ( 2, @child ) + 3 - POWER ( 2, @child )
> END
>
>
Received on Mon Sep 15 2003 - 21:04:30 CEST

Original text of this message