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

Gary O'Keefe wrote:

> Paul wrote:
>
> 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 ;)

I disagree strongly. PL/SQL and the standard packages were never intended to be a full-blown applications development environment. Those who have started to work with Oracle in the last few years are lucky - Back in release 6.0 and previous the pl/sql functionality was extremely limited and yet we felt lucky that we even had it because it made certain tasks easier to perform.

Still, there are easy solutions to many problems if one just takes the time and expends the effort to write a solution. For example, the DBMS_OUTPUT 1M limitation is easily avoided if you use DBMS_PIPE - although this does require that you have a "listener" which will continuously read the pipe output. The same goes for UTL_FILE - if you want more robust file handling, then do it via DBMS_PIPE. As it stands, far too many systems have an extremely serious security hole because DBAs set UTL_FILE_DIR to * rather than listening to the complaints of programmers that they can't work with files in some particular directory. As a result, anyone who knows how to write a pl/sql script can give themselves root privleges in just a couple minutes. If anything, I'd like to see Oracle lock down UTL_FILE to prevent this serious breach of security.

In addition, pl/sql is an interpreted language that must be tokenized internally before it can be run. Stored procedures help with this but in the end a well-written pro-c program will always beat a pl/sql program for performance. I have yet to discover anything that I can't do with a pro-c program once I put my mind to it.

I guess this is the young crop of programmers that are coming up these days. In my early years in the business we even had to write assembly language routines to handle certain tasks - most programmers these days don't know a MOV from a LD. These things you are speaking about simply are not impediments to getting tasks done.

Ken Received on Wed Jul 28 1999 - 09:59:04 CDT