Re: alter table set TABLE ACCESS METHOD

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Jacob Champion <pchampion(at)vmware(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Ashwin Agrawal <aagrawal(at)pivotal(dot)io>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: alter table set TABLE ACCESS METHOD
Date: 2021-07-30 07:22:19
Message-ID: YQOoq17l7qvTBg1g@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 29, 2021 at 08:55:21AM -0700, Jeff Davis wrote:
> I see that ATExecSetTableSpace() also invokes the hook even for a no-
> op. Should we do the same thing for setting the AM?

Looking at the past, it was the intention of 05f3f9c7 to go through
the hook even if SET TABLESPACE does not move the relation, so you are
right that ALTER TABLE is inconsistent to not do the same for LOGGED,
UNLOGGED and ACCESS METHOD if all of them do nothing to trigger a
relation rewrite.

Now, I am a bit biased about this change and if we actually need it
for the no-op path. If we were to do that, I think that we need to
add in AlteredTableInfo a way to track down if any of those
subcommands have been used to allow the case of rewrite == 0 to launch
the hook even if these are no-ops. And I am not sure if that's worth
the code complication for an edge case. We definitely should have a
hook call for the case of rewrite > 0, though.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2021-07-30 07:26:14 Division by zero error in to_char(num, '9.9EEEE')
Previous Message Richard Guo 2021-07-30 07:14:45 Re: Problem about postponing gathering partial paths for topmost scan/join rel