transforms the insert statement and executed the
rule action in the same transaction. So I think it should work.
But I got the same error on both pg13 and pg14.
Is there something I missed here? or is my understanding of the rule system
just simply wrong?
Regards,
Louis Tian
louis.t...@aquamonix.com.au
Hi All,
Wondering whether there is a way to get the row-level security policy name in
the error message when it's violated.
I am only getting a more generic error message like this.
ERROR: new row violates row-level security policy for table "table_name"
Thanks for your help.
void of the aforementioned limitation.
The downside is it is rather verbose.
*Question*
This there a way to do an upsert proper prior to PG15?
*Feature Request*
Given that UPSERT is an *idempotent* operator it is extremely useful.
Would love to see an UPSERT command in PostgreSQL so one can 'upsert' properly
and easily.
Regards,
Louis Tian
table name).
Still wish there would be UPSERT statement that can handle this and make dev
experience better.
Cheers,
Louis Tian
From: Adrian Klaver
Sent: Friday, April 7, 2023 7:00 AM
To: Louis Tian ;
pgsql-general@lists.postgresql.org
Subject: [EXTERNAL]: Re
y it primary key). So the update execute
without error.
I hope the pesudo code above is enough to clarify the difference?
> The MERGE command has various race conditions that are particularly
> relevant to UPSERT type use cases. See the wiki page you referenced
> for a huge amount of inf
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
uld be in my
opinion).
It was just a question just to confirm my understanding so I got what I need,
so thank you all for that.
Cheers,
Louis Tian
From: Adrian Klaver
Sent: Sunday, April 9, 2023 7:51 AM
To: Louis Tian ; Peter Geoghegan
Cc: pgsql-general@lists.postgresql.org
Subject: [EX
t say actual
HTTP PUT request is idempotent.
With the "current_datetime" and "access_count+1", you are effectively changing
the value passing to the UPSERT operator.
Just like how you changed the payload of a PUT, then obviously there is no
reason to expect the state of th
NFLICT DO UPDATE is not complete equivalent to a TRUE upsert.
Cheers,
Louis Tian
-Original Message-
From: Alban Hertroys
Sent: Sunday, April 9, 2023 7:26 PM
To: Louis Tian
Cc: Peter Geoghegan ; pgsql-general@lists.postgresql.org
Subject: [EXTERNAL]: Re: [EXTERNAL]: Re: UPSERT in Postgres
CAU
