MIME-Version: 1.0
References: <CADT4RqCvuRucgqZjKJypsjAPeEg3QBDND4z1JW4mX=X9fWFkpg@mail.gmail.com>
In-Reply-To: <CADT4RqCvuRucgqZjKJypsjAPeEg3QBDND4z1JW4mX=X9fWFkpg@mail.gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Sat, 26 Feb 2022 06:25:22 -0700
Message-ID: <CAKFQuwZYmqiRq5nTh8ghcfSZ0Qsx6AHbzNArMLLEX0xfeSwLOg@mail.gmail.com>
Subject: Re: Document ordering guarantees on INSERT/UPDATE RETURNING clause
To: Shay Rojansky <roji@roji.org>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000004e3a2705d8ebc00f"
Archived-At: <https://www.postgresql.org/message-id/CAKFQuwZYmqiRq5nTh8ghcfSZ0Qsx6AHbzNArMLLEX0xfeSwLOg%40mail.gmail.com>
Precedence: bulk

--0000000000004e3a2705d8ebc00f
Content-Type: text/plain; charset="UTF-8"

On Sat, Feb 26, 2022 at 5:42 AM Shay Rojansky <roji@roji.org> wrote:

> FWIW I've received feedback from a SQL Server engineer that one definitely
> should *not* depend on such ordering there, and that future optimizations
> (e.g. parallel insertion of many rows) could result in row ordering which
> differs from the lexical ordering of the VALUES clause.
>


> That seems very reasonable; if the situation is similar on PostgreSQL,
> then I'd suggest making that very clear in the INSERT[2] and UPDATE[3] docs.
>

There is clearly no mention of such a guarantee in our documentation.

David J.

--0000000000004e3a2705d8ebc00f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif"><span style=3D"font-family:Arial,Helve=
tica,sans-serif">On Sat, Feb 26, 2022 at 5:42 AM Shay Rojansky &lt;<a href=
=3D"mailto:roji@roji.org">roji@roji.org</a>&gt; wrote:</span></div></div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>FWIW I&#39;ve received feedback from a SQL Server eng=
ineer that one definitely should *not* depend on such ordering there, and t=
hat future optimizations (e.g. parallel insertion of many rows) could resul=
t in row ordering which differs from the lexical ordering of the VALUES cla=
use. </div></div></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>That seems very reasonable; if =
the situation is similar on PostgreSQL, then I&#39;d suggest making that ve=
ry clear in the INSERT[2] and UPDATE[3] docs.</div></div></blockquote><div>=
<br></div><div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif">There is clearly no mention of such a guarantee in our do=
cumentation.</div></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif">David J.</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif"><br></div></div></=
div>

--0000000000004e3a2705d8ebc00f--