Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi, Pavel!

On Wed, Aug 21, 2024 at 1:48 PM Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> wrote:
> On Mon, 19 Aug 2024 at 02:24, Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>>
>> On Sat, Aug 10, 2024 at 6:57 PM Dmitry Koval <d(dot)koval(at)postgrespro(dot)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 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.

------
Regards,
Alexander Korotkov
Supabase