Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lrAcH-0000X0-IK for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Jun 2021 02:40:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lrAcG-0002vM-FE for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Jun 2021 02:40:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lrAcG-0002vD-7T for pgsql-hackers@lists.postgresql.org; Thu, 10 Jun 2021 02:40:20 +0000 Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lrAcD-0005yE-Qn for pgsql-hackers@postgresql.org; Thu, 10 Jun 2021 02:40:19 +0000 Received: by mail-io1-xd2b.google.com with SMTP id q7so25140782iob.4 for ; Wed, 09 Jun 2021 19:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to:user-agent; bh=uzotR9VFStgk2KvhwQazDYDX7GyKZ8k5s9N9xs1yOfg=; b=Pee6/AUdmtPWDoN6eHMgqeTMnUISYKsegKQ68FI0PQrCrRunCfPYXxMm7hCIZN4iI7 hZTkRobxTriDXYRIXR6cIIX/Jg869pLlyMQ+5mI8HyKS3jdvbN29OwSQ1Z4H4iO8C6WF 2lcwwZUH2rlrxDL5l4bW4RYCj9m20hc+agkaPWKkYNIq3XDoiSM0xvosodHmtCoX+d9y KoLXLTyo3WWFSDlLWkT8adhQXU/awQ+bsNfqRQ5lUG9cZUfL4jOmS84otzetCNR9t9xH agq2pzE07a5jdN92l9h/mGuWTDJmK/KEgetUNpb9GE74DLHbWeGl/jlV4Q5fMo7eWNju LyGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to:user-agent; bh=uzotR9VFStgk2KvhwQazDYDX7GyKZ8k5s9N9xs1yOfg=; b=h7GYDO44QKhqygG93mFxgRTFZMFESGUPv3MMvuhL9MdUyCS2aBPaGEPM1Aj2CBgMhy ch7HYI8qWBMgfR/NpHfvTY/J56Dp8DQylH/6q3kDQ+LQIxPeIoGnOkxBsdLGtljM27QY 9IeTcfRvsJr0hJ5waDIJghD+uKXsrG2iB3Sqf4o7QXPxF83lpU3t1BD3wfqdOknWK/ZC 55hXWVSDGbcLN4KdxE6I6Qdxo6aNzuFJGCLIt2qkorzU1siEuMIpsdue1JNYh3HxIxR2 laBCzkSq0W5lPzmlNaw9yX4d8bf1MtWUuE3hYVvjU1QLqHh6b9d5yfrhnpIbDjWJCnUV y9qw== X-Gm-Message-State: AOAM5321YqOuSiMBnzPt6jAFv5pOIRC5jiCjR/q0DbppiGGQm352B1pD M/RB3z17KPmQZN6B6Fwb/PJHww== X-Google-Smtp-Source: ABdhPJzGousEjtngU0yps5VLqoyZVLTgMUkqS7a3pjoVldlyQCe9UuIGduCPZJk8Ct64fSNk5QwScw== X-Received: by 2002:a05:6638:267:: with SMTP id x7mr2467916jaq.51.1623292816102; Wed, 09 Jun 2021 19:40:16 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id j18sm928241ila.29.2021.06.09.19.40.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Jun 2021 19:40:15 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 5ACAE800B38; Wed, 9 Jun 2021 21:40:14 -0500 (CDT) Date: Wed, 9 Jun 2021 21:40:14 -0500 From: Justin Pryzby To: Zhihong Yu , Michael Paquier Cc: Jeff Davis , pgsql-hackers@postgresql.org, Jacob Champion , Heikki Linnakangas , Ashwin Agrawal , Ashutosh Sharma , Andres Freund , Robert Haas , Amit Kapila , Alvaro Herrera , Dilip Kumar Subject: Re: alter table set TABLE ACCESS METHOD Message-ID: <20210610024014.GA16435@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jun 09, 2021 at 01:45:52PM -0700, Zhihong Yu wrote: > + /* check if another access method change was already requested > */ > + if (tab->newAccessMethod) > + ereport(ERROR, > + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > + errmsg("cannot change access method setting twice"))); > > I think the error message can be refined - changing access method twice is > supported, as long as the two changes don't overlap. That language is consistent wtih existing errors. src/backend/commands/tablecmds.c: errmsg("cannot change persistence setting twice"))); src/backend/commands/tablecmds.c: errmsg("cannot change persistence setting twice"))); errmsg("cannot alter type of column \"%s\" twice", However, I think that SET TABLESPACE is a better template to follow: errmsg("cannot have multiple SET TABLESPACE subcommands"))); Michael pointed out that there's two, redundant checks: + if (rel->rd_rel->relam == amoid) + return; + + /* Save info for Phase 3 to do the real work */ + if (OidIsValid(tab->newAccessMethod)) + ereport(ERROR, + (errcode(ERRCODE_SYNTAX_ERROR), + errmsg("cannot have multiple SET ACCESS METHOD subcommands"))); I think that the "multiple subcommands" test should be before the "no-op" test. @Jeff: In my original patch, I also proposed patches 2,3: Subject: [PATCH v2 2/3] Allow specifying acccess method of partitioned tables.. Subject: [PATCH v2 3/3] Implement lsyscache get_rel_relam()