Support multi-column renaming?
I have noticed that ALTER TABLE supports multiple column actions
(ADD/DROP column etc), but does not support multiple column renaming.
See [1]https://www.postgresql.org/docs/current/sql-altertable.html
Here is small example of what im talking about:
```
db2=# create table tt();
CREATE TABLE
-- multiple column altering ok
db2=# alter table tt add column i int, add column j int;
ALTER TABLE
-- single column renaming ok
db2=# alter table tt rename column i to i2;
ALTER TABLE
-- multiple column renaming not allowed
db2=# alter table tt rename column i2 to i3, rename column j to j2;
ERROR: syntax error at or near ","
LINE 1: alter table tt rename column i2 to i3, rename column j to j2...
^
db2=#
```
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?
[1]: https://www.postgresql.org/docs/current/sql-altertable.html
--
Best regards,
Kirill Reshke
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).
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming" (A. Stepanov)
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