On Tue, 29 Dec 2020 at 23:08, Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> On Fri, Dec 25, 2020 at 03:41:46PM +0900, Michael Paquier wrote:
> > On Wed, Dec 09, 2020 at 02:13:29PM -0600, Justin Pryzby wrote:
> > > I thought this was a good idea, but didn't hear back when I raised it before.
> > >
> > > Failing to preserve access method is arguably a bug, reminiscent of CREATE
> > > STATISTICS and 5564c1181. But maybe it's not important to backpatch a fix in
> > > this case, since access methods are still evolving.
> >
> > Interesting. Access methods for tables are released for more than one
> > year now, so my take about a backpatch is that this boat has already
> > sailed. This may give a reason to actually not introduce this
> > feature.
>
> Are you saying that since v12/13 didn't preserve the access method, it might be
> preferred to never do it ? I think it's reasonable to not change v12/13 but
> the behavior seems like an omission going forward. It's not so important right
> now, since AMs aren't widely used.
Omitting copying the AM seems like a bug during
CREATE TABLE likeamlike(LIKE likeam INCLUDING ALL);
But this does allow you to specify the TableAM by using
default_table_access_method, and to use
CREATE TABLE likeamlike(LIKE likeam INCLUDING ALL) USING (heapdup);
if you wish to set the AM explicitly, so I don't see this as needing backpatch.
Which means that the emphasis for the earlier functionality was
towards one "preferred AM" rather than using multiple AMs at same
time. Allowing this change in later releases makes sense.
Please make sure this is marked as an incompatibility in the release notes.
> > This patch should have more tests. Something could be added in
> > create_am.sql where there is a fake heap2 as table AM.
>
> Yes, I had already done that locally.
There are no tests for the new functionality, please could you add some?
--
Simon Riggs http://www.EnterpriseDB.com/