Re: MERGE and parsing with prepared statements
On 2022-Jul-15, Justin Pryzby wrote:
Should that sentence be removed from MERGE ?
Removed
On 2022-Jul-18, Justin Pryzby wrote:
On Fri, Jul 15, 2022 at 03:43:41PM -0500, Justin Pryzby wrote:
Should that sentence be removed from MERGE ?
Also, I think these examples should be more similar.
Agreed, done.
On 2022-Aug-09, Justin Pryzby wrote:
On Tue, Aug 09, 2022 at 11:48:23AM +0200, Álvaro Herrera wrote:
So I propose to leave it as
If <command>MERGE</command> attempts an <command>INSERT</command>
and a unique index is present and a duplicate row is concurrently
inserted, then a uniqueness violation error is raised;
<command>MERGE</command> does not attempt to avoid such
errors by restarting evaluation of <literal>MATCHED</literal>
conditions.I think by "leave it as" you mean "change it to".
(Meaning, without referencing UPDATE).
Yes. I suppose we could add a parenthical comment, given that it's
likely the most popular option? Feel free to suggest something
specific.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"People get annoyed when you try to debug them." (Larry Wall)
Import Notes
Reply to msg id not found: 20220809122621.GC19644@telsasoft.com20220718132000.GB18011@telsasoft.com20220715204341.GO18011@telsasoft.com
On Fri, 12 Aug 2022 at 12:20, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
On 2022-Jul-18, Justin Pryzby wrote:
On Fri, Jul 15, 2022 at 03:43:41PM -0500, Justin Pryzby wrote:
Should that sentence be removed from MERGE ?
Also, I think these examples should be more similar.
Agreed, done.
Sorry, but I disagree with this chunk in the latest commit,
specifically, changing the MATCHED from after to before the NOT
MATCHED clause.
The whole point of the second example was to demonstrate that the
order of the MATCHED/NOT MATCHED clauses made no difference.
By changing the examples so they are the same, the sentence at line
573 now makes no sense.
--
Simon Riggs http://www.EnterpriseDB.com/
On 2022-Aug-12, Simon Riggs wrote:
Sorry, but I disagree with this chunk in the latest commit,
specifically, changing the MATCHED from after to before the NOT
MATCHED clause.The whole point of the second example was to demonstrate that the
order of the MATCHED/NOT MATCHED clauses made no difference.By changing the examples so they are the same, the sentence at line
573 now makes no sense.
Hmm, I thought the point of the example was to show that you can replace
the table in the USING clause with a query that retrieves the column;
but you're right, we lost the thing there. Maybe it was too subtle to
the point that I failed to understand it. Perhaps we can put it back
the way it was and explain these two differences (change of data source
*and* clause ordering) more explicitly.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La virtud es el justo medio entre dos defectos" (Aristóteles)
On Fri, Aug 12, 2022 at 01:53:25PM +0200, Alvaro Herrera wrote:
On 2022-Aug-12, Simon Riggs wrote:
Sorry, but I disagree with this chunk in the latest commit,
specifically, changing the MATCHED from after to before the NOT
MATCHED clause.
3d895bc84 also moved a semicolon into the middle of the sql statement.
The whole point of the second example was to demonstrate that the
order of the MATCHED/NOT MATCHED clauses made no difference.By changing the examples so they are the same, the sentence at line
573 now makes no sense.Hmm, I thought the point of the example was to show that you can replace
the table in the USING clause with a query that retrieves the column;
but you're right, we lost the thing there. Maybe it was too subtle to
the point that I failed to understand it. Perhaps we can put it back
the way it was and explain these two differences (change of data source
*and* clause ordering) more explicitly.
Evidently I misunderstood it, too.
--
Justin
On 2022-Aug-12, Simon Riggs wrote:
Sorry, but I disagree with this chunk in the latest commit,
specifically, changing the MATCHED from after to before the NOT
MATCHED clause.The whole point of the second example was to demonstrate that the
order of the MATCHED/NOT MATCHED clauses made no difference.By changing the examples so they are the same, the sentence at line
573 now makes no sense.
Not sure how to fix this. We could add put the WHEN clauses in the
order they were, and add another phrase to that paragraph to explain
more explicitly that the order is not relevant (while at the same time
explaining that if you have multiple WHEN MATCHED clauses, the relative
order of those *is* relevant).
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"At least to kernel hackers, who really are human, despite occasional
rumors to the contrary" (LWN.net)