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>
In-Reply-To: <CAPpHfdu+iX5TP65Cyn6vUe8JKGtLmMA=sKKKgE7tB6G6Qk=18Q@mail.gmail.com>
From: Pavel Borisov <pashkin.elfe@gmail.com>
Date: Wed, 21 Aug 2024 14:48:45 +0400
Message-ID: <CALT9ZEHhVt-i1vGL_eCfNqAisTiC6VaM6U-fxP3kD306uPLEcw@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="000000000000f2af4706202f49ca"
Archived-At: <https://www.postgresql.org/message-id/CALT9ZEHhVt-i1vGL_eCfNqAisTiC6VaM6U-fxP3kD306uPLEcw%40mail.gmail.com>
Precedence: bulk

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

Hi, Alexander!

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@postgrespro=
.ru>
> wrote:
> > > Probably
> > > QueryCompletion struct fits this purpose best from the existing
> > > parameters.  Attached draft patch implements returning oid of newly
> > > created relation as part of QueryCompletion.  Thoughts?
> >
> > I agree, returning the oid of the newly created relation is the best wa=
y
> > 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.

Shouldn't we also modify the TableLikeClause node in gram.y accordingly?

For the comments:
Put the Oid  -> Store the OID
so caller might use it -> for the caller to use it.
(Maybe also caller -> table create function)

Regards,
Pavel Borisov
Supabase

--000000000000f2af4706202f49ca
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 Mon, 19 Aug 2024 at 02:2=
4, 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">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; Probably<br>
&gt; &gt; QueryCompletion struct fits this purpose best from the existing<b=
r>
&gt; &gt; parameters.=C2=A0 Attached draft patch implements returning oid o=
f newly<br>
&gt; &gt; created relation as part of QueryCompletion.=C2=A0 Thoughts?<br>
&gt;<br>
&gt; I agree, returning the oid of the newly created relation is the best w=
ay<br>
&gt; to solve the problem.<br>
&gt; (Excuse me, I won&#39;t have access to a laptop for the next week - an=
d<br>
&gt; won&#39;t be able to look at the source code).<br>
<br>
Thank you for your feedback.=C2=A0 Although, I decided QueryCompletion is<b=
r>
not a good place for this new field.=C2=A0 It looks more appropriate to<br>
place it to TableLikeClause, which already contains one relation oid<br>
inside.=C2=A0 The revised patch is attached.<br></blockquote><div><br></div=
><div>I&#39;ve looked at the patch v2. Remembering the=C2=A0OID of a relati=
on newly created with LIKE in TableLikeClause seems good to me.</div><div>C=
heck-world passes sucessfully.</div><div><br></div><div>Shouldn&#39;t we al=
so modify the TableLikeClause node in gram.y accordingly?</div><div><br></d=
iv><div>For the comments:=C2=A0</div><div>Put the Oid=C2=A0 -&gt; Store the=
 OID</div><div>so caller might use it -&gt; for the caller to use it.=C2=A0=
</div><div>(Maybe also caller -&gt; table create function)<br></div><div><b=
r></div><div>Regards,=C2=A0</div><div>Pavel Borisov</div><div>Supabase</div=
></div></div>

--000000000000f2af4706202f49ca--