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

Paul wrote:

[ To Mr. L. Ellison: "Grrrrr" ]

>1. A "RANDOM" function.
>2. A RANDOMIZE function to accompany "RANDOM" function.
>3. A native "DIV" function. Oracle has MOD an integer remainder
>function but not an integer division function. DIV and MOD always
>appear together, but not in Oracle.
>4. Bitwise boolean functions OR, XOR, AND, NOT (not the same as
>boolean operators). Ever tried to write a decent encryption algorithm
>in Oracle without these? Ever tried to mask an integer to see if a
>bit is set? Just overload the existing boolean operators to allow
>Bitwise boolean opeartions.
>5. TO_HEX function. Are they stupid or what?
>6. TO_BASE function which can handle bases up to 64.
>7. A variant of REPLACE that only replaces the first instance of
>search_string found. Come on Oracle simply overload it and add another
>parameter Max_Replaces (Max_Replaces > 0).
>8. Alter Table RENAME COLUMN .... How bloody obvious is this? How
>many times do you need to be asked? OK you have constraints to
>consider but they know this. We don't like using the data-dictionary
>hack.
>9. Constraint fk_MyForeignKey References MyOtherTable (MyPKField) ON
>UPDATE CASCASE. Is Oracle the only RDBMS that doesn't have a native
>on update cascade?
>10. Constraint fk_MyForeignKey References MyOtherTable (MyPKField) ON
>DELETE SET NULL. Another Oracle gotcha. It is basic referential
>principles. Every single DB design case tool has this but oh no not
>Oracle, it is far too obvious for them.
>11. The ability to find out who is the locker when using pessimistic
>locking (e.g. when "select 1 from MYTable where MyPrimaryKey = MyValue
>for update nowait" fails because someone else has already
>pessimistically locked it.)
>12 The ability to move the cursor back to correct typos in SQL plus.
>Why is it still not possible? Sometimes we haven't gone into another
>editor and we accidentally make a typo at the end of a 200 character
>line, so Oracle makes us retype the whole lot again. SQL Plus is and
>always has been an extremely poor interface.
>13 Polymorphism in Objects. What other object modeling language
>doesn't have Polymorphism? derrrrr
>14. Binary operator XOR.
>15. Give SQL Loader the ability to skip columns in CSV format. Not
>all fields in a CSV file may be needed Oracle, so come on.
>16 Allow Oracle Debugger Probe to watch of implicit loop variables.
>17. Allow "OR REPLACE" syntax on all create object commands.
>etc. etc. etc.

For what it's worth I wouldn't mind seeing DBMS_OUTPUT and UTL_FILE completely revamped. I have always thought that they are a complete shambles. What I'd like to see include:

1. Escape sequences ( \n, \t, ..., etc. )
2. String and print formatting (and getting rid of the nifty "feature" that removes leading spaces when you call dbms_output.put_line).
3. Printing without having to "set serveroutput on" and "dbms_output.enable(...)". I want to print. I wouldn't have written a script with dbms_output.put_line if I didn't want to see it.
4. Raise the output buffer size > 1Mb. This is the 90's for goodness sake. Are we still farting around with teeny DBs? I don't think so.
5. The ability to perform simple, basic file handling procedures simply. I hate the way that loading data from a flat file _requires_ exception handling - hitting the end of a file is _not_ an exception unless it's unexpected. Open, read until EOF, close. What is so damn difficult about maing work that way? This would be really useful in the event that you want to perform a query on a large set of data provided externally. The 255 line limit on an IN clause burns my big one.

The file and print handling in Oracle is so bad that I have given up on PL/SQL in favour of perl. Using the DBD interface is about as fast as PL/SQL and it is *so much* easier to manipulate and format the results of queries it is untrue. How, for goodness' sake, can Oracle let a situation continue where firing a script through perl is easier to work with than a direct interface to the DB with PL/SQL? Are Oracle even aware how shitty and limited PL/SQL is? Yeah, sure, some folk have managed miracles (e.g. Advanced PL/SQL Programming from ORA) but they have to jump through hoops while bending over backwards to do it.

I agree with Paul, within limits, about Oracle's policy of introducing new features instead of fixing what is broken but I think they aren't going to change unless people stop buying their products. Vote with your feet (or maybe write them a nice non-confrontational letter ;)

Gary
--
Gary O'Keefe
gary_at_onegoodidea.com

You know the score - my current employer has nothing to do with what I post Received on Wed Jul 28 1999 - 08:12:43 CDT