每种数据库中都保留了自己所有的关键字，在表的定义过程中同样数据库保存了自己的系统列。看完关于postgresql的系统列部分的文档，还勾起了我想了解postgresql事务如何进行管理的冲动。先对postgresql的系统列进行一下了解，重要的是从中得到一些设计思想上的东西。
对于系统的保留关键字，都是禁止或者不建议用户进行定义时使用的词语。postgresql中的系统列是不允许作为用户定义的列名字段，在现实数据库设计过程中很少使用这些字段名称，所以不需要特别的关注，需要知道它们的存在。

oid
行对象表示符。postgresql为每个表的所有列自动添加该值（除非创建表时采用WITHOUT OIDS选项，该情况下oid列不显示），该列与类型同名。
在oracle中有rowid列，正常情况下是不显示的，也是系统自动生成的值，不是主角不多说。

tableoid
表对象表示符。该列对于从继承层次中进行查询非常有用，如果没有它，就很难说清行记录来自那个表。tableoid列与数据字典pg_class的oid进行关联可以获取表名。
oracle中似乎没有tableoid专有列名，同样可以通过user_objects视图查到表的id，对于判断行属于哪一列，oracle将对象的id号直接放到了rowid中。
oracle的rowid采用64进制表示方式，由18个字符表示：对象编号的6字符+文件编号的3字符+块编号的6字符+行编号的3字符，就是说直接找到行就能知道它属于那个文件，那个对象，在那个块上。

xmin
行版本的插入事务标识。（行版本代表着行的状态，行的每次更新会创建新的版本。）
如果对postgresql的事务管理设计方式不了解，很难清楚这个东西如何工作的。接下来可以好好了解一下事务的管理方式。

cmin
插入事务内的命令标识。（该值从0开始）。
这个更难理解了，插入事务能有多少命令标识?可以推测一下插入的方式不同该值可能不同，还是插入操作所处于不同的状态?，还是需要去了解事务的管理方式。

xmax
删除事务标识。对于非删除的行版本该值是0。该值为非0值时表示删除事务还没有提交，或者试图进行回滚。
也就是说明了该参数值至少有三种，用于表示删除处于的状态。

cmax
删除事务内部的命令标识，或者为0。

ctid
行版本在表中的物理位置。尽管ctid能够快速实现定位版本，但是经过VACUUM FULL之后，行的ctid就会移动或者更新。由此ctid不适于作行的行的长期标识符。
ctid表示的物理位置，如果VACUUM执行发生了行数据的物理移动，那索引又要如何?索引中指向表行位置的id又如何变化，目前对VACUUM没有深入了解，只能猜想是跟着变化。

文档中提到OID是32位的。很难对oid的唯一性作出假设。
事务标识与命令标识都是32位。

虽然从几个关键字很难解释事务管理方式，但是从中也能窥探一点。对象都是存放在文件中的，对象与文件之间又是如何关联在一起的?会不会也象oracle的rowid一样包含着文件号?tableoid与行之间的关系如何?弄清楚这些问题后，对postgresql对数据记录如何进行定位的问题也就能够了解很多。看来要了解更多的postgresql知识需要解决不少问题。

参考文档：http://www.postgresql.org/docs/8.0/interactive/ddl-system-columns.html