A couple of thoughts ...
Row-level locking is not an extension to SQL since one does nothing in the SQL request to obtain row level locking other than to specify a lock. The comparison is to page-level locking, invoked by the same syntax, in which multiple records can be within the same page. The difference is substantial, but it is a performance issue, not an extension to SQL.
Oracle has made extensions to SQL, primarily to provide performance gains, e.g., when the programmer "knows" something about the data which can be used to access it more efficiently. But, I think most of these extensions are more recent.
FWIW, the Progress RDBMS had row level locking from day one in the early 80s, but no meaningful SQL option when everyone climbed on that bandwagon. Goes to show the power of standards, particularly when combined with PRGS history of stealth marketing. PRGS is a good case study of how to have a compelling technical advantage and waste it.
As to the moderate gain in stock price in the initial RDBMS tornado and the more dramatic one later, my guess is that there were some complicating factors. Certainly, the recent years have seen the commoditization of the database and some serious stumbles by Informix and Sybase, which have helped to propel Oracle into its current highly dominant status, a level of dominance it did not have after the first round because there still appeared to be some serious other contenders in the game. While I am fuzzy on the details, my memory is that Oracle "helped" limit the dramatic gains by some major earnings stumbles back then, which probably help to explain the limited gain in stock price, despite a quite commanding position. |
