On 2023-03-29 12:15:09 -0700, Adrian Klaver wrote:
> On 3/29/23 09:43, Peter J. Holzer wrote:
> > On 2023-03-29 07:59:54 -0700, Adrian Klaver wrote:
> > > On 3/29/23 07:19, Sebastien Flaesch wrote:
> > > > INSERT statements must not use the serial column, so you have to
> > > > list all columns of
On Thu, 2023-03-30 at 14:32 +0200, Dominique Devienne wrote:
> I fail to see that myself, sorry. You can bind NULL, you can bind values, so
> why
> wouldn't you be able to bind DEFAULT too? I see that more as a failing to the
> binding API myself :)
That doesn't work because DEFAULT is not a valu
On Thu, Mar 30, 2023 at 11:42 AM Francisco Olarte
wrote:
> On Thu, 30 Mar 2023 at 10:01, Dominique Devienne
> wrote:
> > 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
>
On Thu, 30 Mar 2023 at 10:01, Dominique Devienne 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 i
On Wed, Mar 29, 2023 at 9:23 PM Adrian Klaver
wrote:
> On 3/29/23 12:11, Sebastien Flaesch wrote:
> > Oh the use of default keyword is new to me, thanks for that.
> >
> > But to make PostgreSQL more Informix-compatible,
> > zero should have been considered as well.
Perhaps.
> 1) Why? Down the
: Using CTID system column as a "temporary" primary key
EXTERNAL: Do not click links or open attachments if you do not recognize the
sender.
> On 29 Mar 2023, at 21:11, Sebastien Flaesch wrote:
>
> Oh the use of default keyword is new to me, thanks for that.
>
> Bu
On Wed, 29 Mar 2023 at 21:11, Sebastien Flaesch
wrote:
> Oh the use of default keyword is new to me, thanks for that.
> But to make PostgreSQL more Informix-compatible, zero should have been
> considered as well.
NONONO please! Someone already pointed a sequence can generate zero,
but even witho
> On 29 Mar 2023, at 21:11, Sebastien Flaesch wrote:
>
> Oh the use of default keyword is new to me, thanks for that.
>
> But to make PostgreSQL more Informix-compatible, zero should have been
> considered as well.
…No, I’m not going to be humble about this opinion… Postgres does a sane thin
On 3/29/23 12:11, Sebastien Flaesch wrote:
Oh the use of default keyword is new to me, thanks for that.
But to make PostgreSQL more Informix-compatible, zero should have been
considered as well.
1) Why? Down the road to compatibility with some undetermined group of
databases lies mayhem.
> On Mar 29, 2023, at 12:11, Sebastien Flaesch
> wrote:
> But to make PostgreSQL more Informix-compatible, zero should have been
> considered as well.
There is an infinite family of strange features that various databases have
(DUAL from Oracle, anyone?); PostgreSQL will rapidly become unus
On 3/29/23 09:43, Peter J. Holzer wrote:
On 2023-03-29 07:59:54 -0700, Adrian Klaver wrote:
On 3/29/23 07:19, Sebastien Flaesch wrote:
INSERT statements must not use the serial column, so you have to list
all columns of the table and provide only the values of the non-serial
columns. With Infor
say : no, using zero was not considered.
😉
Seb
From: Adrian Klaver
Sent: Wednesday, March 29, 2023 4:59 PM
To: Sebastien Flaesch ; Kirk Wolak
Cc: Geoff Winkless ; pgsql-general
Subject: Re: Using CTID system column as a "temporary" primary key
EXTERNAL: Do n
Ok... sounds not good all in all.
Appreciate your help!
Thanks!
From: Laurenz Albe
Sent: Wednesday, March 29, 2023 5:53 PM
To: Sebastien Flaesch ; Kirk Wolak
Cc: Geoff Winkless ; pgsql-general
Subject: Re: Using CTID system column as a "temporary" p
On 2023-03-29 07:59:54 -0700, Adrian Klaver wrote:
> On 3/29/23 07:19, Sebastien Flaesch wrote:
> > INSERT statements must not use the serial column, so you have to list
> > all columns of the table and provide only the values of the non-serial
> > columns. With Informix you could just specific a z
On Wed, 2023-03-29 at 14:23 +, Sebastien Flaesch wrote:
> From: Laurenz Albe
> > It is safe to assume that the CTID is stable within a single transaction
> > only if you use REPEATABLE READ or better transaction isolation level.
> >
> > With READ COMMITTED, you see updated rows (and consequent
On 3/29/23 07:19, Sebastien Flaesch wrote:
Hello Kirk,
INSERT statements must not use the serial column, so you have to list
all columns of the table and provide only the values of the non-serial
columns. With Informix you could just specific a zero to get a new
generated serial, but seems
Laurent,
Thanks for the advice about REPEATABLE READ isolation level!
Seb
From: Laurenz Albe
Sent: Wednesday, March 29, 2023 1:08 PM
To: Kirk Wolak ; Sebastien Flaesch
Cc: Geoff Winkless ; pgsql-general
Subject: Re: Using CTID system column as a "temp
TID system column as a "temporary" primary key
EXTERNAL: Do not click links or open attachments if you do not recognize the
sender.
On Tue, Mar 28, 2023 at 6:40 AM Sebastien Flaesch
mailto:sebastien.flae...@4js.com>> wrote:
...
I think if you're honest with yourself you
On Tue, 2023-03-28 at 14:24 -0400, Kirk Wolak wrote:
>
> I cringe at the thought of using CTID. And while it's probably "safe enough"
> inside a single transaction. I doubt that there is much "testing" of this
> concept.
It is safe to assume that the CTID is stable within a single transaction
On Tue, Mar 28, 2023 at 6:40 AM Sebastien Flaesch
wrote:
> ...
>
>
> I think if you're honest with yourself you already know the answer to this
> question. The only real solution is to update the legacy code to use the
> primary key, or (if that's not possible) change the table definition to add
Note that VACUUM FULL and CLUSTER can update ctids. I don't believe regular
VACUUM can, so you should be safe from autovacuum interfering in this
scheme, but the ctid colum documentation [1] states "A primary key should
be used to identify logical rows," so this is not exactly intended usage.
Than
CAST seems to do the job so that's a good solution here.
Seb
From: Christophe Pettus
Sent: Tuesday, March 28, 2023 2:39 PM
To: Sebastien Flaesch
Cc: Geoff Winkless ; pgsql-general
Subject: Re: Using CTID system column as a "temporary" primary ke
> On Mar 28, 2023, at 03:39, Sebastien Flaesch
> wrote:
> Do I have to cast() ?
Yes:
select * from t where ctid='(0,1)'::tid;
The string representation can be up to 17 characters: 10 for the page number, 4
for the tuple number, and three for the delimiters.
Remember that updating
: Sebastien Flaesch
Cc: pgsql-general
Subject: Re: Using CTID system column as a "temporary" primary key
EXTERNAL: Do not click links or open attachments if you do not recognize the
sender.
On Tue, 28 Mar 2023 at 10:28, Sebastien Flaesch
mailto:sebastien.flae...@4js.com>> wrot
rom: Sebastien Flaesch
Sent: Tuesday, March 28, 2023 11:57 AM
To: pgsql-general
Subject: Re: Using CTID system column as a "temporary" primary key
EXTERNAL: Do not click links or open attachments if you do not recognize the
sender.
I mean Oracle's ROWID of course, not ROWNUM.
ROWNUM i
On Tue, 28 Mar 2023 at 10:28, Sebastien Flaesch
wrote:
> Is the CTID a good choice?
>
I think if you're honest with yourself you already know the answer to this
question. The only real solution is to update the legacy code to use the
primary key, or (if that's not possible) change the table defi
I mean Oracle's ROWID of course, not ROWNUM.
ROWNUM is temporary in the context of the SELECT, so it cannot be used in
subsequent SQL statements.
Seb
From: Sebastien Flaesch
Sent: Tuesday, March 28, 2023 11:28 AM
To: pgsql-general
Subject: Using CTID system colum
27 matches
Mail list logo
