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/