Re: Oracle #1? Then why are these still missing...

From: Will Bailey <willbailey_at_nospam.com>
Date: 1999/07/29
Message-ID: <37a14c5d.82277248_at_news.cix.co.uk>


On Thu, 29 Jul 1999 11:21:01 GMT, tkyte_at_us.oracle.com (Thomas Kyte - Oracle employee) doing his usual explanation / work around for simple things that are missing from Oracle when they shouldn't be wrote:

>
>>Paul wrote:
>>
>>[ earlier stuff about bitand snipped ]
>>
>>>Thomas Kyte wrote:
>>>>and you can always write your own bitor and other functions. for example:
>>>>
>>>>CREATE OR replace FUNCTION bitor( x IN NUMBER, y IN NUMBER ) RETURN NUMBER
>>>> AS
>>>> l_x PLS_INTEGER DEFAULT x;
>>>> l_y PLS_INTEGER DEFAULT y;
>>>> l_r PLS_INTEGER DEFAULT 0;
>>>> l_tmp PLS_INTEGER := 1;
>>>>BEGIN
>>>> FOR i IN 1 .. 32 LOOP
>>>> IF ( bitand(l_x,l_tmp) = l_tmp OR bitand(l_y,l_tmp) = l_tmp )
>>>> THEN
>>>> l_r := l_r + l_tmp;
>>>> END IF;
>>>> l_tmp := l_tmp * 2;
>>>> exit when ( l_tmp >= l_x AND l_tmp >= l_y );
>>>> END LOOP;
>>>>
>>>> RETURN l_r;
>>>>END;
>>>>/
>>
>>[ misc stuff snipped ]
>>
>>>>>14. Binary operator XOR.
>>>>
>>>>as easy as bitor
>>>>
>>>>SQL> CREATE OR replace FUNCTION bitxor( x IN NUMBER, y IN NUMBER ) RETURN NUMBER
>>>> 2 AS
>>>> 3 l_x PLS_INTEGER DEFAULT x;
>>>> 4 l_y PLS_INTEGER DEFAULT y;
>>>> 5 l_r PLS_INTEGER DEFAULT 0;
>>>> 6 l_tmp PLS_INTEGER := 1;
>>>> 7 BEGIN
>>>> 8 FOR i IN 1 .. 32 LOOP
>>>> 9 IF ( bitand(l_x,l_tmp) <> bitand(l_y,l_tmp) )
>>>> 10 THEN
>>>> 11 l_r := l_r + l_tmp;
>>>> 12 END IF;
>>>> 13 l_tmp := l_tmp * 2;
>>>> 14 exit when ( l_tmp >= l_x AND l_tmp >= l_y );
>>>> 15 END LOOP;
>>>> 16
>>>> 16 RETURN l_r;
>>>> 17 END;
>>>> 18 /
>>>>
>>>>Function created.
>>
>>Not to put you down Thomas, but these are horrible. On any modern
>
>gee, i found them to be useful -- and fast enough.
 Gee, and coincidentally you work for Oracle.
>

 [snip]
>>Argghhh! I just noticed that you call bitand twice per loop. What is
>
>lets see you do it *without* calling bitand 2 times -- its sort of important (it
>won't work unless you do). Also, in the first one (bitor) bitand is only called
>2 times if the first call and compare is FALSE.
Mmm OK BitOR without two BitAND calls and a lot of looped convoluted code...

create or replace function BitOR(x number, y number) return number /* Action : Performs bitwise OR between two values */ /* Notes : Won't handle negative values, this is oracle's fault because BitAND doesn't*/
is
begin
  return (x + y) - BitAND(x, y);
end;

create or replace function BitXOR(x number, y number) return number /* Action : Performs bitwise XOR between two values */ /* Notes : Won't handle negative values, this is oracle's fault because BitAND doesn't*/
is
begin
  return BitOR(x, y) - BitAND(x, y);
end;

But you still make excuses, excuses, excuses for PL/SQL having missing basic functionality. Listen, why the hell doesn't Oracle just add BitOR and BitXOR and XOR. You've spent so much time bullshitting around, just to explain why obvious implicit things aren't in Oracle when they should be. Like why BitOR and BitXOR aren't in PL/SQL when BitAND is? WHY? WHY? WHY? Explain Oracle's logic in excluding them and the other things you've worked around. C'mon let's hear it. You can't can you? Because you are yet another brainwashed Oracle employee protecting the achilles tendon in the giant Oracle machine.

When Oracle is good it is very good, but when it is bad it is rotten. Missing fundamentals are what makes Oracle rotten. Release after release after release fundamentals still remain missing, and probably will for ever and a day. Oracle simply doesn't listen hard enough - always excuses never action and reaction.

>
>If i didn't call bitand 2 times -- then you could say "argghhh", your algorithm
>is botched. I actually spent a bit of time trying many different
>implementations to discover this to be the fastest I could code.
>
>>this - Voyage to the Bottom of the Performance? What is the point in
>
>No. If you call bitor, bitxor a couple of dozen times
>
>>buying a dog and barking yourself? The ALU is an integral component of
>>the processor - use it! I appreciate the effort in implementing these
>>algorithms, but it is misguided to attempt these sorts of operations
>>in PL/SQL.
>>
>
>Lets see -- plsql doesn't have bitor. I find a need to do bitor. I write a
>bitor. Misguided me I guess -- I just gave myself the ability to do something I
>needed to do (and presumably will have to do one way or another) and previously
>could not.

Let's see -- plsql doesn't have BitOR but has BitAND. I could write a bitor, but then again during the process I might ask myself: why am I wasting my development time supplementing Oracle's tool set because of basic missing functionality? I might get angry about this, and I might ask myself is it because they are just plain dumb and think that no-one would possibly actually need it? Or is it that they simply ignore people's continual requests for it and other missing stuff to be natively added. Likewise with many of the other issues raised by the original posting that you worked around.

>
>I could take the above code and implement it in java, I could take it an
>implement it in C. I found the above to be
But WHY! when it should be in PL/SQL. You are using another language to patch simple things missing in PL/SQL. God, you really don't see it do you? Can't you see why we gripe?
>
>- the most portable (everyone with 7.1 and up can use it)
>
>- the easiest to understand and install (this is pretty important to me as I'd
>get thousands of emails with questions and installation issues for anything more
>complex)
>
>- works *fast enough* for most things.
>
>True -- its not as fast as C (i can say that in general about plsql) but it
>works, it does the job, and it is only one of at least 3 ways I know how to do
>this, each with various performance and implementation implications.
>
>
>>Gary

Will Bailey Received on Thu Jul 29 1999 - 00:00:00 CEST

Original text of this message