Nathan Bossart <nathandbossart@gmail.com> wrote:
> On Thu, Aug 27, 2026 at 10:11:45AM -0500, Nathan Bossart wrote:
> > The REPACK grammar accepts ONLY and a trailing * like VACUUM does, but it's
> > neither documented nor handled in the REPACK code. From a v19 perspective,
> > it might be best to just reject that syntax for now, but that does mean it
> > won't be able to do everything VACUUM (FULL) can.
>
> Bringing REPACK in line with its documentation looks pretty simple. This
> is probably the way to go for v19, as proper support for ONLY and trailing
> * seems to require more invasive changes.
>
> diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
> index a33c3aaeeb2..2df39a48fc6 100644
> --- a/src/backend/parser/gram.y
> +++ b/src/backend/parser/gram.y
> @@ -12543,25 +12543,25 @@ CreateConversionStmt:
> *****************************************************************************/
>
> RepackStmt:
> - REPACK opt_utility_option_list vacuum_relation USING INDEX name
> + REPACK opt_utility_option_list qualified_name opt_name_list USING INDEX name
> {
> RepackStmt *n = makeNode(RepackStmt);
>
> n->command = REPACK_COMMAND_REPACK;
> - n->relation = (VacuumRelation *) $3;
> - n->indexname = $6;
> + n->relation = makeVacuumRelation($3, InvalidOid, $4);
> + n->indexname = $7;
> n->usingindex = true;
> n->params = $2;
> $$ = (Node *) n;
> }
> - | REPACK opt_utility_option_list vacuum_relation opt_usingindex
> + | REPACK opt_utility_option_list qualified_name opt_name_list opt_usingindex
> {
> RepackStmt *n = makeNode(RepackStmt);
>
> n->command = REPACK_COMMAND_REPACK;
> - n->relation = (VacuumRelation *) $3;
> + n->relation = makeVacuumRelation($3, InvalidOid, $4);
> n->indexname = NULL;
> - n->usingindex = $4;
> + n->usingindex = $5;
> n->params = $2;
> $$ = (Node *) n;
> }
At the moment, I can't think of other reason for using the 'vacuum_relation'
rule than the effort to replace both CLUSTER and VACUUM FULL. Unfortunately it
appears that the difference in the command arguments was missed. What you
propose LGTM, thanks.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
