Re: Cleanup/remove/update references to OID column - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Cleanup/remove/update references to OID column
Date
Msg-id da5a314d-f92d-47ef-b005-8451f26de0f2@manitou-mail.org
Whole thread Raw
In response to Cleanup/remove/update references to OID column  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Cleanup/remove/update references to OID column
List pgsql-hackers
    Justin Pryzby wrote:

> Cleanup/remove/update references to OID column...
>
> ..in wake of 578b229718e8f.

Just spotted a couple of other references that need updates:

#1. In catalogs.sgml:

     <row>
      <entry><structfield>attnum</structfield></entry>
      <entry><type>int2</type></entry>
      <entry></entry>
      <entry>
       The number of the column.  Ordinary columns are numbered from 1
       up.  System columns, such as <structfield>oid</structfield>,
       have (arbitrary) negative numbers.
      </entry>
     </row>

oid should be replaced by xmin or some other system column.


#2. In ddl.sgml, when describing ctid:

     <para>
      The physical location of the row version within its table.  Note that
      although the <structfield>ctid</structfield> can be used to
      locate the row version very quickly, a row's
      <structfield>ctid</structfield> will change if it is
      updated or moved by <command>VACUUM FULL</command>.  Therefore
      <structfield>ctid</structfield> is useless as a long-term row
      identifier.  The OID, or even better a user-defined serial
      number, should be used to identify logical rows.
     </para>

"The OID" used to refer to an entry above in that list, now it's not
clear what it refers to.
"serial number" also sounds somewhat obsolete now that IDENTITY is
supported. The last sentence could be changed to:
 "A primary key should be used to identify logical rows".


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: block-level incremental backup
Next
From: Robert Haas
Date:
Subject: Re: block-level incremental backup