Horton

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Pavel Borisov <pashkin.elfe@gmail.com>

View thread
From: Pavel Borisov <pashkin.elfe@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Dmitry Koval <d.koval@postgrespro.ru>, Noah Misch <noah@leadboat.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-08-21T12:06:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Adjust errcode in checkPartition()

  2. Fix usage of palloc() in MERGE/SPLIT PARTITION(s) code

  3. Implement ALTER TABLE ... SPLIT PARTITION ... command

  4. Implement ALTER TABLE ... MERGE PARTITIONS ... command

  5. Calculate agglevelsup correctly when Aggref contains a CTE.

  6. Use PqMsg_* macros in applyparallelworker.c.

  7. Restrict psql meta-commands in plain-text dumps.

  8. Ensure we have a snapshot when updating various system catalogs.

  9. Use specific collation where needed in new test

  10. Expand virtual generated columns in the planner

  11. Virtual generated columns

  12. Define PG_LOGICAL_DIR for path pg_logical/ in data folder

  13. Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands

  14. Avoid repeated table name lookups in createPartitionTable()

  15. Provide deterministic order for catalog queries in partition_split.sql

  16. Don't copy extended statistics during MERGE/SPLIT partition operations

  17. Fix the name collision detection in MERGE/SPLIT partition operations

  18. Fix regression tests conflict in 3ca43dbbb6

  19. Add permission check for MERGE/SPLIT partition operations

  20. Fix one more portability shortcoming in new test_pg_dump test.

  21. Inherit parent's AM for partition MERGE/SPLIT operations

  22. Add tab completion for partition MERGE/SPLIT operations

  23. Rename tables in tests of partition MERGE/SPLIT operations

  24. Make new partitions with parent's persistence during MERGE/SPLIT

  25. Document the way partition MERGE/SPLIT operations create new partitions

  26. Change the way ATExecMergePartitions() handles the name collision

  27. Grammar fixes for split/merge partitions code

  28. Checks for ALTER TABLE ... SPLIT/MERGE PARTITIONS ... commands

  29. Fix some grammer errors from error messages and codes comments

  30. Support TZ and OF format codes in to_timestamp().

  31. Support identity columns in partitioned tables

  32. Fix indentation in twophase.c

  33. Fix corner-case planner failure for MERGE.

  34. Doc: fix documentation example for bytea hex output format.

  35. Avoid repeated name lookups during table and index DDL.

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 PM 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 PM 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
> 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.