On 2024-Apr-17, Michael Paquier wrote: > Yeah, that would be easy enough to track but I was wondering about > adding the relkind instead. Still, one thing that I found confusing > is the dump generated in this case, as it would mix the SET and the > ALTER TABLE commands so one reading the dumps may wonder why the SET > has no effect for a CREATE TABLE PARTITION OF without USING. Perhaps > that's fine and I just worry too much ;)
Hmm, maybe we should do a RESET of default_table_access_method before printing the CREATE TABLE to avoid the confusion. > The extra ALTER commands need to be generated after the object > definitions, so we'd need a new subroutine similar to > _selectTableAccessMethod() like a _selectTableAccessMethodNoStorage(). > Or grouping both together is just simpler? I think there should be two routines, since _select* routines just print a SET command; maybe the new one would be _printAlterTableAM() or something like that. Having _select() print an ALTER TABLE command depending on relkind (or the boolean flag) would be confusing, I think. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
