MIME-Version: 1.0
References: <171085360143.2046436.7217841141682511557.pgcf@coridan.postgresql.org>
 <171085858750.2046434.12246066729700037354.pgcf@coridan.postgresql.org>
 <909e16b4-9eda-435c-b033-8294ae4adc05@postgrespro.ru> <CAPpHfdsVQwnZPxaQPwcu1g_01F0d-o=ECRcf14X3CmavJB6vSQ@mail.gmail.com>
 <a83d5a56-ff33-47e8-b2d8-7e9a5d59ee1e@postgrespro.ru> <CAPpHfdsCCV8DOv0Ovu4dTSnuWXiEz_AjuW-J6TPj++tcfEGvRw@mail.gmail.com>
 <3a4b9c1c-3edf-4e29-9629-b4113aefb0f3@postgrespro.ru> <CAPpHfduNYkMVuUSxZjD6u4tZG6aKdhgQcmhr-K9OQfeg56MNww@mail.gmail.com>
 <c3730d78-6081-4c41-9715-d1d192734576@postgrespro.ru> <CAPpHfdtj7YsPaASoVPN+N3H4_Ct+kQw8QY1d_9u7FPnbghkicw@mail.gmail.com>
 <20240808171351.a9.nmisch@google.com> <19c1e04c-2012-4475-8460-821dd633a6ce@postgrespro.ru>
 <CAPpHfdtYgQ8PUZMS043c8USeKcKh5isrAW0QQKMAxQacX-+nuA@mail.gmail.com>
 <768cbb42-d3f8-45de-89ad-72861f078dc2@postgrespro.ru> <CAPpHfdu+iX5TP65Cyn6vUe8JKGtLmMA=sKKKgE7tB6G6Qk=18Q@mail.gmail.com>
 <CALT9ZEHhVt-i1vGL_eCfNqAisTiC6VaM6U-fxP3kD306uPLEcw@mail.gmail.com> <CAPpHfdsEtAWhpcPEaUky+gO20=rz0P03OskAS0c8teuTtHP9hQ@mail.gmail.com>
In-Reply-To: <CAPpHfdsEtAWhpcPEaUky+gO20=rz0P03OskAS0c8teuTtHP9hQ@mail.gmail.com>
From: Pavel Borisov <pashkin.elfe@gmail.com>
Date: Wed, 21 Aug 2024 16:06:31 +0400
Message-ID: <CALT9ZEGTFdwrP+jO1tKxHHeGPM-enMm734MP0wCwJTQZDembYA@mail.gmail.com>
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Dmitry Koval <d.koval@postgrespro.ru>, Noah Misch <noah@leadboat.com>, 
	pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000151b6f06203060e1"
Archived-At: <https://www.postgresql.org/message-id/CALT9ZEGTFdwrP%2BjO1tKxHHeGPM-enMm734MP0wCwJTQZDembYA%40mail.gmail.com>
Precedence: bulk

--000000000000151b6f06203060e1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, Alexander!

On Wed, 21 Aug 2024 at 15:55, Alexander Korotkov <aekorotkov@gmail.com>
wrote:

> Hi, Pavel!
>
> On Wed, Aug 21, 2024 at 1:48=E2=80=AFPM Pavel Borisov <pashkin.elfe@gmail=
.com>
> wrote:
> > On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov <aekorotkov@gmail.com>
> wrote:
> >>
> >> On Sat, Aug 10, 2024 at 6:57=E2=80=AFPM Dmitry Koval <d.koval@postgres=
pro.ru>
> wrote:
> >> > > Probably
> >> > > QueryCompletion struct fits this purpose best from the existing
> >> > > parameters.  Attached draft patch implements returning oid of newl=
y
> >> > > created relation as part of QueryCompletion.  Thoughts?
> >> >
> >> > I agree, returning the oid of the newly created relation is the best
> way
> >> > to solve the problem.
> >> > (Excuse me, I won't have access to a laptop for the next week - and
> >> > won't be able to look at the source code).
> >>
> >> Thank you for your feedback.  Although, I decided QueryCompletion is
> >> not a good place for this new field.  It looks more appropriate to
> >> place it to TableLikeClause, which already contains one relation oid
> >> inside.  The revised patch is attached.
> >
> >
> > I've looked at the patch v2. Remembering the OID of a relation newly
> created with LIKE in TableLikeClause seems good to me.
> > Check-world passes sucessfully.
>
> Thank you.
>
> > Shouldn't we also modify the TableLikeClause node in gram.y accordingly=
?
>
> On the one hand, makeNode() uses palloc0() and initializes all fields
> with zero anyway.  On the other hand, there is already assignment of
> relationOid.  So, yes I'll add assignment of newRelationOid for the
> sake of uniformity.
>
> > For the comments:
> > Put the Oid  -> Store the OID

> so caller might use it -> for the caller to use it.
>
> Accepted.
>
> > (Maybe also caller -> table create function)
>
> I'll prefer to leave it "caller" as more generic term, which could
> also fit potential future usages.
>
> The revised patch is attached.  I'm going to push it if no objections.
>
Looked at v3
All good except the patch has "Oid" and "OID" in two comments. I suppose
"OID" is preferred elsewhere in the PG comments.

Regards,
Pavel.

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi, Alexander!</div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 21 Aug 2024 at 15:5=
5, Alexander Korotkov &lt;<a href=3D"mailto:aekorotkov@gmail.com">aekorotko=
v@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Hi, Pavel!<br>
<br>
On Wed, Aug 21, 2024 at 1:48=E2=80=AFPM Pavel Borisov &lt;<a href=3D"mailto=
:pashkin.elfe@gmail.com" target=3D"_blank">pashkin.elfe@gmail.com</a>&gt; w=
rote:<br>
&gt; On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov &lt;<a href=3D"mailto=
:aekorotkov@gmail.com" target=3D"_blank">aekorotkov@gmail.com</a>&gt; wrote=
:<br>
&gt;&gt;<br>
&gt;&gt; On Sat, Aug 10, 2024 at 6:57=E2=80=AFPM Dmitry Koval &lt;<a href=
=3D"mailto:d.koval@postgrespro.ru" target=3D"_blank">d.koval@postgrespro.ru=
</a>&gt; wrote:<br>
&gt;&gt; &gt; &gt; Probably<br>
&gt;&gt; &gt; &gt; QueryCompletion struct fits this purpose best from the e=
xisting<br>
&gt;&gt; &gt; &gt; parameters.=C2=A0 Attached draft patch implements return=
ing oid of newly<br>
&gt;&gt; &gt; &gt; created relation as part of QueryCompletion.=C2=A0 Thoug=
hts?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I agree, returning the oid of the newly created relation is t=
he best way<br>
&gt;&gt; &gt; to solve the problem.<br>
&gt;&gt; &gt; (Excuse me, I won&#39;t have access to a laptop for the next =
week - and<br>
&gt;&gt; &gt; won&#39;t be able to look at the source code).<br>
&gt;&gt;<br>
&gt;&gt; Thank you for your feedback.=C2=A0 Although, I decided QueryComple=
tion is<br>
&gt;&gt; not a good place for this new field.=C2=A0 It looks more appropria=
te to<br>
&gt;&gt; place it to TableLikeClause, which already contains one relation o=
id<br>
&gt;&gt; inside.=C2=A0 The revised patch is attached.<br>
&gt;<br>
&gt;<br>
&gt; I&#39;ve looked at the patch v2. Remembering the OID of a relation new=
ly created with LIKE in TableLikeClause seems good to me.<br>
&gt; Check-world passes sucessfully.<br>
<br>
Thank you.<br>
<br>
&gt; Shouldn&#39;t we also modify the TableLikeClause node in gram.y accord=
ingly?<br>
<br>
On the one hand, makeNode() uses palloc0() and initializes all fields<br>
with zero anyway.=C2=A0 On the other hand, there is already assignment of<b=
r>
relationOid.=C2=A0 So, yes I&#39;ll add assignment of newRelationOid for th=
e<br>
sake of uniformity.<br>
<br>
&gt; For the comments:<br>
&gt; Put the Oid=C2=A0 -&gt; Store the OID=C2=A0</blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
&gt; so caller might use it -&gt; for the caller to use it.<br>
<br>
Accepted.<br>
<br>
&gt; (Maybe also caller -&gt; table create function)<br>
<br>
I&#39;ll prefer to leave it &quot;caller&quot; as more generic term, which =
could<br>
also fit potential future usages.<br>
<br>
The revised patch is attached.=C2=A0 I&#39;m going to push it if no objecti=
ons.<br></blockquote><div>Looked=C2=A0at v3</div><div>All good except the p=
atch has=C2=A0&quot;Oid&quot; and &quot;OID&quot; in two comments. I suppos=
e &quot;OID&quot; is preferred elsewhere in the PG comments.</div><div><br>=
</div><div>Regards,</div><div>Pavel.</div></div></div>

--000000000000151b6f06203060e1--