Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Wed, Aug 21, 2024 at 3:06 PM Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> wrote:
> On Wed, 21 Aug 2024 at 15:55, Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>>
>> 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.
>
> 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.

Correct, the same file contains "OID" multiple times. Revised version
is attached.

------
Regards,
Alexander Korotkov
Supabase