Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rfukG-00362h-O8 for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Mar 2024 04:43:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rfukE-00B5QC-6F for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Mar 2024 04:43:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rfukD-00B5Q4-SX for pgsql-hackers@lists.postgresql.org; Fri, 01 Mar 2024 04:43:38 +0000 Received: from mail-yb1-f175.google.com ([209.85.219.175]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rfukA-002GhJ-E2 for pgsql-hackers@postgresql.org; Fri, 01 Mar 2024 04:43:36 +0000 Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-db4364ecd6aso1939062276.2 for ; Thu, 29 Feb 2024 20:43:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709268215; x=1709873015; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KC2dfEExqtnvYU4KZoYauY3rzlk0RvAAxI7EI9nnDyc=; b=L+086bBXm2eQLGR1qXiZ2JlJJi/+AIVQEq4PI2nC5XOmvOsXnWOIsNfucbQQ/IoFHF 8YG8Jq7Aa4215FnrGKHSoAyYou+0WQVB6zewsDk9C1rEG7PmXsOS3DTyKpud9HQHSrUl LhiPnVdEOY1B/kmZfRl3+dKjbPGtPxp46ocQwE/fj0RCfr+pi0bObZokLVroj8hEEkAw uLZLZKe07CniIOp3mdmSNwhGguNuY08buVaXqkd/YZukC3vLXCjV/VKP6ubj9KeYwsjH kHiGbTWTutdJVUTBxmB6BnkAj3Em+fnC2in14B30CUmbOaVCgXd88ThYUGzZ6AVbLqAw aiSw== X-Forwarded-Encrypted: i=1; AJvYcCW0aP/AkUFfQ0g0O4BPNSyTbPOqW7WVqCBUChTwhb+C9uFc97cr6UePYB+u1FTUVg/rLLkf4owgLCBvQJOhr4v3qRlEpWU3W8aDGyei X-Gm-Message-State: AOJu0YyqcAPdGHOPerA4Y5VetXjYfgXC4ER7GN90xY/Z8dG/WEtMeMVJ b9lXXb6sJ0fDoZow5lOI4rE7NCOytDyimNv6GAlYyl/wmA1mievmhqS7wktNZhQ0bd1kRp1lUhV DgLop8W0JJm0JIKuzZjAyAL+vPu2dY/qaLrXVlw== X-Google-Smtp-Source: AGHT+IG9/PNYf9s2GqXXCUrE25U0MK+EuSefQ1+i7iOcug2EdP1ilM2QyJ8gc9Q6LfjI8P9nMtz0eGm1hRxjTXO7ed4= X-Received: by 2002:a25:ac4:0:b0:dcd:3575:db79 with SMTP id 187-20020a250ac4000000b00dcd3575db79mr466732ybk.6.1709268214949; Thu, 29 Feb 2024 20:43:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jelte Fennema-Nio Date: Fri, 1 Mar 2024 05:43:25 +0100 Message-ID: Subject: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables To: Michael Paquier Cc: Justin Pryzby , Peter Eisentraut , Soumyadeep Chakraborty , Zhihong Yu , pgsql-hackers@postgresql.org, Ashwin Agrawal , vanjared@vmware.com Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 1 Mar 2024 at 02:57, Michael Paquier wrote: > When it comes to partitioned tables, there is a still a tricky case: > what should we do when a user specifies a non-default value in the SET > ACCESS METHOD clause and it matches default_table_access_method? > Should the relam be 0 or should we force relam to be the OID of the > given value given by the query? Implementation-wise, forcing the > value to 0 is simpler, but I can get why it could be confusing as > well, because the state of the catalogs does not reflect what was > provided in the query. At the same time, the user has explicitly set > the access method to be the same as the default, so perhaps 0 makes > sense anyway in this case. I think we should set the AM OID explicitly. Because an important thing to consider is: What behaviour makes sense when later default_table_access_method is changed? I think if someone sets it explicitly on the partitioned table, they would want the AM of the partitioned table to stay the same when default_table_access_method is changed. Which requires storing the AM OID afaict.