Re: Using CTID system column as a "temporary" primary key - Mailing list pgsql-general

From Francisco Olarte
Subject Re: Using CTID system column as a "temporary" primary key
Date
Msg-id CA+bJJbyDM5ej+JYAgzybqnDti9PTjykAEGAymA81eXm+Gmfmxw@mail.gmail.com
Whole thread Raw
In response to Re: Using CTID system column as a "temporary" primary key  (Dominique Devienne <ddevienne@gmail.com>)
Responses Re: Using CTID system column as a "temporary" primary key
List pgsql-general
On Thu, 30 Mar 2023 at 10:01, Dominique Devienne <ddevienne@gmail.com> wrote:
>> 2) 0 can be a valid sequence value:
> Of course. Yet, as above, if that is opt-in as specified in the `create table` DDL somehow, then why not?
> BTW, default and 0 are not the same thing. You cannot bind "default" in place of
> an integer-valued prepared-statement placeholder, in a binary mode insert. So it is
> definitely not the same thing.

IMNSHO if you need to select between default and explicit in an insert
via binding you have a design problem, and down this path lies
madness.

> So while I can accept that not implementing that particular informix compatibility wart
> is a perfectly valid position, for impl and maintenance cost, the arguments I've read so
> far can be "easily" side-stepped from a technical perspective I suspect. FWIW.

Do not forget the runtime costs, once you start piling informix warts
over oracle warts over access warts over sybase warts over mysql warts
over sql server warts it adds up.

I do not think postgres target should be compatibilty with (select
sql_engine order by random limit n). Normally it tries to follow
standards, and do something reasonable when not possible, but this
informix wart sounds particularly worthless to implement. Beside your
use case I do not think it would serve for anything else than
encouraging people to use an ill dessigned informix feature.

Francisco Olarte.



pgsql-general by date:

Previous
From: Florents Tselai
Date:
Subject: Multilang text search. Is this correct?
Next
From: David Rowley
Date:
Subject: Re: Get dead tuples data