REPACK and naming - Mailing list pgsql-hackers

From David G. Johnston
Subject REPACK and naming
Date
Msg-id CAKFQuwYremPM3s50e_a0MBwz37=Djg=tOExeVzcto9aW2NudZg@mail.gmail.com
Whole thread Raw
In response to Re: REPACK and naming  (Marcos Pegoraro <marcos@f10.com.br>)
Responses Re: REPACK and naming
Re: REPACK and naming
List pgsql-hackers
On Wednesday, September 17, 2025, Marcos Pegoraro <marcos@f10.com.br> wrote:
Em ter., 16 de set. de 2025 às 23:01, Robert Haas <robertmhaas@gmail.com> escreveu:
I think RETABLE is not a proposal to be taken seriously. That's
extremely confusing.

This feature could be used in a future version to rearrange fields in a table, for better padding.
I don't think we have another one available for this purpose.

CREATE TABLE T(A text, B integer, C bigint, D integer);

We could have something like
RETABLE T USING(B, D, C, A)

That changes logical aspects of a table and so would be done as part of alter table, IMO. “AT tbl Rearrange columns (names list) “

I’m not a fan of “retable” as a command keyword.

But this digresses from the topic at hand.

I’m fine with repack itself.  Deprecating vacuum full would be nice - but actually renaming existing things is bound to just make matters worse, IMO.

Concretely, maybe we should remove vacuum full from the vacuum command page, and just call it out as compatibility spelling of repack on its page.  Maybe do the same for cluster (I haven’t dived into the new feature enough to confidently describe all this yet though).

David J.

pgsql-hackers by date:

Previous
From: Daniil Davydov
Date:
Subject: Re: [BUG] Query with postgres fwd deletes more tuples than it should
Next
From: Greg Burd
Date:
Subject: Re: [PATCH] Add tests for Bitmapset