Someone needs to work on humor, grammar and logic!

You say RM is based on mathmatics.  Well, 2+2=4 is just an opinion, a
convention.  Didn't you read your Orwell?  *eyeroll* I used to think
the world would end up like 1984...then Huxley seemed to be onto
something.  I'd never imagined we'd have a hidious blend of both, the
destruction of reasoning by the force of society - voluntarily - while
everyone laughs as if Somatized.  Some in this bunch have made me think
twice.  

Lets examine an example of Oracle extensions to SQL and commercially
expedient solutions for problems .

1) Extensions : eg ROWID and ROWNUM pseudo-columns

Rowid is a transient identifier of a row of a base table which as we
know happens to correspond to the address of the physical
representation of the row (storage).

So what do Oracle hope to achieve (other than performance) by exposing
an implementation detail from the physical data model through the
logical data model ?

In general to provide an even more convenient way to update or delete a
single row than having to specify  match conditions for all key columns
in the WHERE clause and specifically to facilitate a method for
updating absolutely identical rows (duplicates) .

eg consider a table with 2 identical rows which could arise because SQL
does not insist a table has a key (which is an RM (relational model)
requirement) . How can you update or delete 1 of those rows ?

UPDATE table_name SET col1=val1 WHERE .....  AND ROWNUM =1
UPDATE table_name SET col1=val1 WHERE ROWID = &VAR     /  WHERE CURRENT
OF CURSOR

Now here is the key point , is it better to provide extensions to allow
processing of individual duplicated rows or would it have been better
to outlaw duplicate rows by insisting each table has a key ?

The features which provide row level processing just do not incentivise
people to elevate their thinking to consider sets of data rather than
individual objects and this is holding data management back .

2) Constraint Support

Did you know that a constraint is any condition you can think of which
must evaluate to true (in binary logic) in order for an update of the
database to be plausible ?   (in SQL's inconsistent 3 valued logic it
must evaluate to NOT FALSE ) .

Is there anyone who has contributed to this thread who would not like
Oracle to support more constraints than it does and thinks Oracle
constraint support is adequate as it stands ?

Eg i) a declarative constraint to ensure each invoice must have at
least 1 line item (which can only be simulated with a constraint on a
materialised view which outer joins invoice_header and
invoice_line_item ) .
eg ii) to ensure that the key values of 3 tables are disjoint - ie a
key value is unique accross more than 1 table
eg iii) an exclusion constraint to match the FK inclusion constraint eg
to ensure that a key value does not exist in another table .

To my knowledge the only enhancement to constraints Oracle has made
since 7.3 is deferring checking to commit time .  I welcome this
expedient solution but through studying recognise that it is
problematic and have become aware that it is not even the only way DBMS
products could address the problem .

7.3 is about 13 years old , zoom forward to 2018 - how confident are
you that Oracle will have significantly enhanced it's constraint
support by then ?

3) Data-types and domain support

In Oracle User defined datatypes are difficult to define and use .

Wouldn't you like to be able to do rudimentary things simply like
define a datatype of country_code based on a built-in datatype such as
varchar2(2) and then add a column to a table as follows ADD
(nationality TYPE country_code NOT NULL) and be able to deal with it AS
CONVENIENTLY as if it has been defined as VARCHAR2(2) ?

ROWNUM is a hack that predated analytical SQL extensions, and some of
these extensions do make sence for an end user. Otherwise, how do you
express the query

"list all the employees with their salary ranks"

?

Oracle materialized view support might have a lot to be desired, but
that's a different story.

As far as performance concerned, there is no reason why it can't be the
same.

Note, that unlike rownum hack, it would also provide an answer with
negated predicate

where rn >= 37

and people would stop asking why rownum doesn't return any rows.