From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Matthias Apitz <guru(at)unixarea(dot)de>, Ron <ronljohnsonjr(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: lifetime of the old CTID |
Date: | 2022-07-06 20:15:09 |
Message-ID: | 96007955-10da-48b4-129a-a3e8abf4ffb6@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 7/6/22 12:51, Matthias Apitz wrote:
> El día miércoles, julio 06, 2022 a las 02:33:42p. m. -0500, Ron escribió:
>
>> On 7/6/22 01:18, Matthias Apitz wrote:
>> [snip]
>>> Ofc, each table has its own primary key(s), used for example for the
>>> SELECT ctid, * FROM d01buch WHERE ...
>>>
>>> As I said, we came to PostgreSQL from Sybase (and Oracle) and Sybase has
>>> for each table a so called SYB_IDENTITY_COLUMN which is static for the
>>> table and its value does not change.
>>
>> The DBA who designed that should be flogged for pretending that
>> SYB_IDENTITY_COLUMN is a primary key.
>
> Now things are coing to blaming. Nobody said that SYB_IDENTITY_COLUMN
> is a primary key, but it is uniqu to identify a row in a table once
> known.
Which is the definition of a PRIMARY KEY. At any rate as has been noted
repeatedly ctid is not that.
>
> matthias
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-07-06 20:26:49 | Re: Seems to be impossible to set a NULL search_path |
Previous Message | Bryn Llewellyn | 2022-07-06 20:13:25 | Re: Seems to be impossible to set a NULL search_path |