Re: Custom reloptions and lock modes

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Subject: Re: Custom reloptions and lock modes
Date: 2019-09-20 01:44:45
Message-ID: 20190920014445.GF1844@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 20, 2019 at 10:38:31AM +0900, Michael Paquier wrote:
> Hi all,
>
> This is a new thread related to the bug analyzed here:
> https://www.postgresql.org/message-id/20190919083203.GC21144@paquier.xyz
>
> And in short, if you attempt to do an ALTER TABLE with a custom
> reloptions the command burns itself, like that for example this
> sequence:
> create extension bloom;
> create table aa (a int);
> create index aa_bloom ON aa USING bloom (a);
> alter index aa_bloom set (length = 20);
>
> Which results in the following error:
> - 0002 is a patch which we could use to extend the existing reloption
> APIs to set the lock mode used. I am aware of the recent work done by
> Nikolay in CC to rework this API set, but I am unsure where we are
> going there, and the resulting patch is actually very short, being
> 20-line long with the current infrastructure. That could go into
> HEAD. Table AMs have been added in v12 so custom reloptions could
> gain more in popularity, but as we are very close to the release it
> would not be cool to break those APIs. The patch simplicity could
> also be a reason sufficient for a back-patch, and I don't think that
> there are many users of them yet.

I mean a back-patch down to v12 for this part, but not further down.
Sorry for the possible confusion.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-09-20 02:06:34 Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly
Previous Message Michael Paquier 2019-09-20 01:42:33 Re: Syntax highlighting for Postgres spec files