On Fri, Mar 01, 2024 at 05:43:25AM +0100, Jelte Fennema-Nio wrote:
> I think we should set the AM OID explicitly. Because an important
> thing to consider is: What behaviour makes sense when later
> default_table_access_method is changed?
Per the latest discussion of the thread, we've kind of reached a
consensus that we should keep the current historical bevahior on
default, where relam remains at 0, causing new partitions to grab the
GUC as AM. If we create a partitioned table attached to a partitioned
table, it should be 0 as well. If the partitioned table has a non-0
relam, a new partitioned table created on it will inherit the same
non-0 value.
> I think if someone sets it explicitly on the partitioned table, they
> would want the AM of the partitioned table to stay the same when
> default_table_access_method is changed. Which requires storing the AM
> OID afaict.
If we allow relam to be non-0 for a partitioned table, it is equally
important to give users a way to reset it at will. My point was a bit
more subtle than that. For example, this sequence is clear to me:
SET default_table_access_method = 'foo';
ALTER TABLE part SET ACCESS METHOD DEFAULT;
The user wants to rely on the GUC, so relam should be 0, new
partitions created on it will use the GUC.
Now, what should this sequence mean? See:
SET default_table_access_method = 'foo';
ALTER TABLE part SET ACCESS METHOD foo;
Should the relam be 0 because the user requested a match with the GUC,
or use the OID of the AM? There has to be some difference with
tablespaces, because relations with physical storage (tables,
matviews) can use a reltablespace of 0, but AMs have to be set for
tables and matviews.
Fun topic, especially once coupled with the internals of tablecmds.c
that uses InvalidOid for the new access AM as a special value to work
as a no-op.
--
Michael