Re: Rearranging ALTER TABLE to avoid multi-operations bugs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Date
Msg-id 23856.1567527697@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rearranging ALTER TABLE to avoid multi-operations bugs  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom: CFbot says this patch doesn't apply anymore.  Could you please
> rebase?

Robert doesn't like the whole approach [1], so I'm not seeing much
point in rebasing the current patch.  The idea I'd been thinking
about instead was to invent a new AlterTableType enum value for
each type of utility command that we can currently generate as a
result of parse analysis of ALTER TABLE, then emit those currently
separate commands as AlterTableCmds with "def" pointing to the
relevant utility-command parsetree, and then add code to ALTER
TABLE to call the appropriate execution functions directly rather
than via ProcessUtility.  (This will add significantly more code
than what I had, and I'm not convinced it's better, just different.)

I haven't gotten to that yet, and now that the CF has started I'm
not sure if I'll have time for it this month.  Maybe we should just
mark the CF entry as RWF for now, or push it out to the next fest.

            regards, tom lane

[1] https://www.postgresql.org/message-id/CA%2BTgmoa3FzZvWriJmqquvAbf8GxrC9YM9umBb18j5M69iuq9bg%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Next
From: Alvaro Herrera
Date:
Subject: Re: Patch: New GUC prepared_statement_limit to limit memory used byprepared statements