Re: cmax docs seem misleading - Mailing list pgsql-docs

From Tom Lane
Subject Re: cmax docs seem misleading
Date
Msg-id 1857026.1774813531@sss.pgh.pa.us
Whole thread Raw
In response to cmax docs seem misleading  (Paul A Jungwirth <pj@illuminatedcomputing.com>)
Responses Re: cmax docs seem misleading
List pgsql-docs
Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> The docs for cmax say:[0]
>> The command identifier within the deleting transaction, or zero.

> This was true once upon a time, I think. But nowadays cmax and cmin
> are the same physical field, and the user-facing system columns don't
> seem to be trying to interpret it.

Yeah, this is a mess.  Nobody ever updated this text when we decided we
could pack those fields into one.  I think it would be better to do
what you suggest:

> ... And maybe we should be more drastic: combine cmin &
> cmax into one entry, and explain that they are two names for the same
> value, which might signify the insert cid, the delete cid, or a
> combocid.

I'm not sure about good wording, but maybe like

  cmin, cmax:

    Originally, cmin and cmax were separate fields.  cmin was the
    inserting command's command identifier within the inserting
    transaction, while cmax was the updating or deleting command's
    command identifier within the updating/deleting transaction, or
    zero if no update or delete attempt had occurred yet.  Nowadays
    these system columns refer to the same field and will always read
    as the same value.  That might be the inserting command's command
    identifier, or the deleting command's command identifier, or a
    "combocid" that reflects both actions when those happened in the
    same transaction.

I don't know if we want to go into any more detail than that.

            regards, tom lane



pgsql-docs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Correct docs about GiST leaf page structure
Next
From: Paul A Jungwirth
Date:
Subject: Re: Correct docs about GiST leaf page structure