Re: What is the rowid composed of?

HansF <News.Hans_at_telus.net> wrote:

>On Thu, 13 Oct 2005 10:23:50 -0500, Turkbear interested us by writing:
>
>> HansF <News.Hans_at_telus.net> wrote:
>>
>>>On Wed, 12 Oct 2005 18:39:59 -0400, Robert interested us by writing:
>>>
>>>>
>>>> Why would you quote a SINGLE sentence in that huge document to make a point
>>>> ???
>>>
>>>Avoid debate. There are many on either side of this topic. By quoting
>>>the book, I avoid getting caught in the middle.
>>
>>
>> But quoting only part of the book is misleading -
>
>I had hoped that LINKING, in addition to QUOTING would lead the OP to the
>relevant section to read on their own. AND I had hoped that the caveat I
>provided would head off stupidity like this. I guess I need to start
>quoting more and provide even more references. <Sigh>
>
>> There is really no debate..The ROWID can ( and does) change...
>
>Here we go ... Oracle docco vs Turkbear.
>
>Here are a few of Oracle's public docco references to 'rowid doesn't
>change'.
>
>(And I do recognize there is a philosophical debate - if a row is
>replaced with a clone, say via export/import, for any number of reasons
>such as to eliminate row migration, is it the same row or is it a new row
>with identical data as the original?)
>
>--------------------------
>Concepts:
>
>Glossary: ROWID
>
>A globally unique identifier for a row in a database. It is created at the
>time the row is inserted into a table, and destroyed when it is removed
>from a table.
>
>Data Type area, under 'Physical Rowid'
>
>A row's assigned rowid remains unchanged unless the row is exported and
>imported using the Import and Export utilities. When you delete a row from
>a table and then commit the encompassing transaction, the deleted row's
>associated rowid can be assigned to a row inserted in a subsequent
>transaction.
>
>Under 'How are ROWID's used"
>
>Before you use rowids in DML statements, they should be verified and
>guaranteed not to change. The intended rows should be locked so they
>cannot be deleted.
>
>Under "Comparison between Logical and Physical rowids"
>
>A row's logical rowid does not change as long as the primary key value
>does not change. This is less stable than the physical rowid, which stays
>immutable through all updates to the row.
>
>Under "Row Chaining and Migration"
>
>The rowid of a migrated row does not change.
>
>Administrator's Guide (10gR1):
>
>Chapter 20, section "Eliminating Migrated or Chained Rows in a Table" goes
>through an interesting discussion which basically says 'Delete and
>recreate the row to get a new rowid'
>
>SQL Reference (10gR1):
>
>Chapter 2/Datatypes: UROWID Datatype
>
>Each row in a database has an address. However, the rows of some tables
>have addresses that are not physical or permanent or were not generated by
>Oracle Database. For example, the row addresses of index-organized tables
>are stored in index leaves, which can move. Rowids of foreign tables (such
>as DB2 tables accessed through a gateway) are not standard Oracle rowids.
>
>Oracle uses universal rowids (urowids) to store the addresses of
>index-organized and foreign tables. Index-organized tables have logical
>urowids and foreign tables have foreign urowids. Both types of urowid are
>stored in the ROWID pseudocolumn (as are the physical rowids of
>heap-organized tables).
>
>Oracle creates logical rowids based on the primary key of the table. The
>logical rowids do not change as long as the primary key does not change.
>
>--------------------------
>I find Oracle's descriptive terms such as 'remains unchanged', 'immutable'
>and 'rowid does not change as long as the primary key does not change'
>strangely compelling.
>
>There are a lot more references but I'm tired of cutting and pasting ...
>
>Your turn. I am eager to log a documentation TAR based on your proof.
No debate with Oracle's docs, they are correct.

It just does not say what you seem to be insisting on: that the ROWID never changes. ( I will grant that there can be some confusion with Logical vs Physical ) But,

If it changes with an EXP or INP then it changes...

If it can be reused when a row is deleted, it has changed ( in as far as what it identifies)

If 'rowid does not change as long as the primary key does not change' then it changes when the primary key changes.

The phrase 'does not change' is an absolute and cannot be qualified by an 'except when' or a 'unless' clause..Either it stays the same ( in identification and/or meaning) or it changes..

But this may be more a language usage issue than an Oracle one.. It is like saying something is 'almost perfect' - an impossibility, since 'perfect' is a unique and unqualified state.. something can be 'nearly perfect' however..

. Received on Tue Oct 18 2005 - 08:50:39 CDT