Re: ON CONFLICT DO SELECT (take 3) - Mailing list pgsql-hackers

From Viktor Holmberg
Subject Re: ON CONFLICT DO SELECT (take 3)
Date
Msg-id 1864b4a5-d572-47e6-afff-ed9fedd02935@Spark
Whole thread Raw
In response to Re: ON CONFLICT DO SELECT (take 3)  (jian he <jian.universality@gmail.com>)
Responses Re: ON CONFLICT DO SELECT (take 3)
List pgsql-hackers
There are some white spaces in v19.
Sorry, what do you mean "white spaces”? Is it a problem?
it's time to squash the patchset into one, IMHO.
you can also begin to write the draft commit message, explain what this is all
about.
Yes, done.
ExecOnConflictSelect
if (lockStrength == LCS_NONE)
{
/* Evem if the tuple is deleted, it must still be physically present */
Assert(table_tuple_fetch_row_version(relation, conflictTid,
SnapshotAny, existing));
}
this is wrong, i think.
buildtype=release, the Assert macro will always be true,
the whole Assert may be optimized out,
and later code would have trouble using (TupleTableSlot *existing).
Yes, you’re right. Nice catch. Fixed.
updatable_views.sql: I did some ON CONFLICT DO SELECT permissions checks, and
other tests in it, please check attached.
Added

-----
I’ve updated all the comments you mentioned.
Thanks for the review Jian, I’m hoping we’ve caught all the issues now.
Please find v20 attached.
Attachment

pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: Undefined behavior detected by new clang's ubsan
Next
From: Tom Lane
Date:
Subject: Re: Can we remove support for standard_conforming_strings = off yet?