Re: Hints in Practice

Bob Jones wrote:
>>> The point was that the hints used in the SQL are non-standard, therefore
>>> not portable.
>> So is Oracle's use of NULL. And there is no workaround. So is Oracle's
>> security model with roles, and system and object privileges. So is
>> Oracle's transaction model. So is Oracle's MVCC. If you make the choice
>> to use Oracle ... then embrace Oracle.
>>

> 
> These are architectural differences. You don't bring all these with you when 
> moving to a different platform.

So don't bring the hints. No one forces you to keep hints while using the other product's definition of NULL.

>>> Exactly. Putting hints in the SQL violates all that.
>> Do reads not blocking writes violate things? How about writes not
>> blocking reads? And as pointed out by others here Oracle is not the
>> only RDBMS with hints? There is no place to hide. If you don't like
>> them ... don't use them. It isn't worth the energy you are putting
>> into this.

>
> Again, you are missing my point. We are talking about portable code here.

No you're not. You just dismissed the fact that NULL, transaction models and locking are completely different as being irrelevant as though they don't affect code portability but hints do? Please reconsider what you are saying.

> Yes, DB2 also has hints, but they do not require the change of SQL.

And Oracle's hints do? How?

The following is perfectly valid Oracle syntax:

SELECT /*+ Bob Jones is making an argument that doesn't hold water */ table_name
FROM user_tables;

And if you don't believe me ... copy it into SQL*Plus.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org