Re: alter table set TABLE ACCESS METHOD - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: alter table set TABLE ACCESS METHOD
Date
Msg-id bfad9843733672c468783532fd440731aceb1f8f.camel@j-davis.com
Whole thread Raw
List pgsql-hackers
On Wed, 2021-07-28 at 14:02 +0900, Michael Paquier wrote:
> Arg, sorry about that!  I was unclear what the situation of the patch
> was.

No problem, race condition ;-)

> Right.  Isn't that an older issue though?  A rewrite involved after a
> change of relpersistence does not call the hook either.  It looks to
> me that this should be after finish_heap_swap() to match with
> ATExecSetTableSpace() in ATRewriteTables().  The only known user of
> object_access_hook in the core code is sepgsql, so this would
> involve a change of behavior.  And I don't recall any backpatching
> that added a post-alter hook.

Sounds like it should be a different patch. Thank you.

> > Also, I agree with Justin that it should fail when there are
> > multiple
> > SET ACCESS METHOD subcommands consistently, regardless of whether
> > one
> > is a no-op, and it should probably throw a syntax error to match
> > SET
> > TABLESPACE.
> 
> Hmm.  Okay.
> 
> > Minor nit: in tab-complete.c, why does it say "<smt>"? Is that just
> > a
> > typo or is there a reason it's different from everything else,
> > which
> > uses "<sth>"? And what does "sth" mean anyway?
> 
> "Something".  That should be "<sth>" to be consistent with the area.

These two issues are pretty minor.

Regards,
    Jeff Davis





pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Out-of-memory error reports in libpq
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] test/ssl: rework the sslfiles Makefile target