On 2023-04-10 14:35:38 +0200, Karsten Hilbert wrote:
> All I really wanted to hint at is that "incoming call
> timestamp" may work pretty well in given settings but does
> not _always_ make for a "unique enough" key.
This is true for all natural primary keys: Any attribute of an entity
which is un
Am Mon, Apr 10, 2023 at 01:33:41PM +0200 schrieb Francisco Olarte:
> > > > This the part that's always eluded me: How does the client, the
> > > > UPSERTer, come to hold an id and not know whether or not it's already in
> > > > the database.
> > >
> > > This is extremely easy to do if you have nat
Hi karsten:
On Mon, 10 Apr 2023 at 11:40, Karsten Hilbert wrote:
>
> Am Mon, Apr 10, 2023 at 09:41:15AM +0200 schrieb Francisco Olarte:
>
> > On Mon, 10 Apr 2023 at 04:16, Rob Sargent wrote:
> > > > An UPSERT checks whether a row exists, if so, it does an update, if not
> > > > it does an inser
Am Mon, Apr 10, 2023 at 09:41:15AM +0200 schrieb Francisco Olarte:
> On Mon, 10 Apr 2023 at 04:16, Rob Sargent wrote:
> > > An UPSERT checks whether a row exists, if so, it does an update, if not
> > > it does an insert. This is the literal definition.
> > This the part that's always eluded me:
Hi Rob:
On Mon, 10 Apr 2023 at 04:16, Rob Sargent wrote:
> > An UPSERT checks whether a row exists, if so, it does an update, if not it
> > does an insert. This is the literal definition.
> This the part that's always eluded me: How does the client, the
> UPSERTer, come to hold an id and not kno
Hi Louis:
On Mon, 10 Apr 2023 at 03:05, Louis Tian wrote:
> I think we need to make a distinction between an "operation" and a
> "statement".
OK
> The concept of idempotency applies to an "operation" not an entire statement.
I think I'll need a definition of both to say anything on this.
> Lik
On 4/9/23 19:16, Rob Sargent wrote:
On 4/9/23 19:55, Louis Tian wrote:
Hi Alban,
"I am not expecting an error here", by "here" I means when doing a
TRUE UPSERT (an upsert current does not exist in Postgres).
I am NOT referring to an "Insert on conflict do update" (which despite
its intention
On 4/9/23 19:55, Louis Tian wrote:
Hi Alban,
"I am not expecting an error here", by "here" I means when doing a TRUE UPSERT
(an upsert current does not exist in Postgres).
I am NOT referring to an "Insert on conflict do update" (which despite its
intention and wide acceptance is not fully equi
Hi Alban,
"I am not expecting an error here", by "here" I means when doing a TRUE UPSERT
(an upsert current does not exist in Postgres).
I am NOT referring to an "Insert on conflict do update" (which despite its
intention and wide acceptance is not fully equivalent to a true upsert).
I underst
Hi Francisco,
I think we need to make a distinction between an "operation" and a "statement".
The concept of idempotency applies to an "operation" not an entire statement.
Like how HTTP "PUT" method is defined as "idempotent", you don't say actual
HTTP PUT request is idempotent.
With the "curr
Hi Adrian,
> No it is not as Israel Brewster pointed out.
I think we need make a distinction between an operation and a statement here
The examples Israel presented and yours are both non-idempotent statements
because the different value being upserted each time the statement is executed.
Not b
From: Israel Brewster
Sent: Sunday, April 9, 2023 3:09 AM
To: Louis Tian
Cc: Peter Geoghegan ; pgsql-general@lists.postgresql.org
Subject: [EXTERNAL]: Re: [EXTERNAL]: Re: UPSERT in Postgres
Thanks Israel. Your example really helped me to understand where we d
12 matches
Mail list logo
