Re: Support multi-column renaming? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Support multi-column renaming?
Date
Msg-id wpuakpcx5hfe3zqkyrbrp2u2ri5hfabqmymqi73ixztvzs2u4b@2jwnvvheacnw
Whole thread Raw
In response to Re: Support multi-column renaming?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Hi,

On 2024-08-06 10:45:48 -0400, Alvaro Herrera wrote:
> On 2024-Aug-06, Kirill Reshke wrote:
> 
> > I have noticed that ALTER TABLE supports multiple column actions
> > (ADD/DROP column etc), but does not support multiple column renaming.
> 
> > Looking closely on gram.y, the only reason for this is that RenameStmt
> > is defined less flexible than alter_table_cmds (which is a list). All
> > other core infrastructure is ready to allow $subj.
> > 
> > So is it worth a patch?
> 
> Hmm, yeah, maybe it'd be better if ALTER TABLE RENAME is not part of
> RenameStmt but instead part of AlterTableStmt.  Probably not a super
> trivial code change, but it should be doable.  The interactions with
> different subcommands types in the same command should be considered
> carefully (as well as with ALTER {VIEW,SEQUENCE,etc} RENAME, which I bet
> we don't want changed due to the implications).

I think you'd likely run into grammar ambiguity issues if you did it
naively. I think I looked at something related at some point in the past and
concluded that to avoid bison getting confused (afaict the grammar is still
LALR(1), it's just that bison doesn't merge states well enough), we'd have to
invent a RENAME_TO_P and inject that "manually" in base_yylex().

IIRC introducing RENAME_TO_P (as well as SET_SCHEMA_P, OWNER TO) did actually
result in a decent size reduction of the grammar.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Minor refactorings to eliminate some static buffers
Next
From: Nathan Bossart
Date:
Subject: Re: remove volatile qualifiers from pg_stat_statements