Re: lifetime of the old CTID - Mailing list pgsql-general

From Christophe Pettus
Subject Re: lifetime of the old CTID
Date
Msg-id A294E4C1-1177-401D-B170-BE9A7D0C959A@thebuild.com
Whole thread Raw
In response to Re: lifetime of the old CTID  (Matthias Apitz <guru@unixarea.de>)
List pgsql-general

> On Jul 6, 2022, at 12:51, Matthias Apitz <guru@unixarea.de> wrote:
> it is uniqu to identify a row in a table once
> known.

I think the point that we are trying to make here is that a ctid *isn't* that.  There is no guarantee, at all, at any
level,that the ctid of a row will remain stable, not even between two SELECT statements.  (Although it doesn't right
now,I could easily image some kind of repack logic in PostgreSQL that runs on read operations, not just write.)  It
shouldn'tbe considered an API.  I understand that it might be painful to change to a generated primary key, but I think
thatwill be less painful in the long run than having to stay ahead of PostgreSQL's internals. 


pgsql-general by date:

Previous
From: Matthias Apitz
Date:
Subject: Re: lifetime of the old CTID
Next
From: "David G. Johnston"
Date:
Subject: Re: Seems to be impossible to set a NULL search_path