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.96) (envelope-from ) id 1w0MbH-001qSQ-1F for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Mar 2026 16:39:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w0MbF-00A9lr-1r for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Mar 2026 16:39:58 +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.96) (envelope-from ) id 1w0MbF-00A9lh-0Y for pgsql-hackers@lists.postgresql.org; Wed, 11 Mar 2026 16:39:57 +0000 Received: from mail-oo1-xc34.google.com ([2607:f8b0:4864:20::c34]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w0MbD-00000001dT5-2KSG for pgsql-hackers@lists.postgresql.org; Wed, 11 Mar 2026 16:39:56 +0000 Received: by mail-oo1-xc34.google.com with SMTP id 006d021491bc7-67bb4e8955aso67970eaf.0 for ; Wed, 11 Mar 2026 09:39:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773247195; cv=none; d=google.com; s=arc-20240605; b=SxEj3pJD+Jm7F74HHShB53YyGvM5jj1TaORszGJxvCr+dhDpznUhH1TtbNvcTJYuJo tYCrsI8pYyz9hDoCyIHPRe3qRNnIRnc/nd+/mwMwRWb8LgG7QlUhxYAC4INoSspOw3vK qjqYWWMIoXdAgSc1svdJLPX12DlzUj7VekCgolZ56LE+A1vj4DJtlhm9fQCR2HWVJCLq lsQBInOD4hEHiwe16xH65vrb7KqN+iSFtsAM6EEeYolVf9YN2BPcCvRhbCyGTmk5PO4A 4DQziMIFB0k69oEtmhzAHglj6IF67eR9Qt2dlQz7w8712Yp7hivV2fsfw4VqwbsnMsTi eArg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=BG2HZ7i0yiFy4LmuVgonhroQBnDsRptg7hafESJ/xtU=; fh=JFcsmRU3uj7ZY18cUWeAtIizUIlyZESasM8jTIcAKRc=; b=IAvpymk3/n3iFam151jm51ngARHcuHpHVB/y7U29LcD26QqXOdZMHUlenLMdg1mzxI vQWTv8l9qUf1Ku80NzqPtHnqvLrRhPsuSmlO+djHBby/sDSZeQUZSq+0KTQGTQ4SzCJb p4A3Zb2zsyvLajcyGlH5Y4Nl6rta6vvTw8lzFhCOQQVFHMRRTpuYCRlvAsMerTmQu4gH DeY1BApfuA8PwHuQjkCVDo7ySBm6hQswZRIzmKTaItYDiNxfp6PyBn7hza6ANK30i5ZT tYB6dLpDNlz/4zLTZaFBQbp5o+3641MtiXEN6TNvoHyo9p3eSzrUiGaGZh8/W53HRJST Zmiw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773247195; x=1773851995; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BG2HZ7i0yiFy4LmuVgonhroQBnDsRptg7hafESJ/xtU=; b=MK/dGyiOm5989wR7DQziM+CkHeni0p0yaSoz33hZ7n2bJfnKLnZWjW/Z0kQ5U9lgBP JAPqB5c+mIANEctSN9ZpafDmkZxCpzoUsDj5BCeoN1OVn72e4Aw6Ko0soSt4nYLtgR2c KxgVGMsuPAlp5Lm1t1enEj1cqETvkjy0b3HEZmeKduRbfY41tPqAkrejWIeFChC6kWjG 2gEKHo2/ghmj0zxaj8RyTJNQI7ZhOI5AOR441x98UsuGsvFwTUgDnPiS66B987Dfwx0o c8eSLxYuMLQlTbLYLhcpcLMfIPbR1ZAz+k/mhmbXU8bgYNjQZKAFkC+gdL7cowNH9bMe 48eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773247195; x=1773851995; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BG2HZ7i0yiFy4LmuVgonhroQBnDsRptg7hafESJ/xtU=; b=DIzrxmCbAkSYrH4szWKLtZiP/PueJRJR+R0cKfOt+TeuLrDxEPVFht0Uhts0rPercB h4Y3fSOvWHlxtH4VuUoJNRzlBVHwCtxLP49E8VkZYetE68S2gm9qCbdM7y7rTIAq64yY 59fVLb8/1k+t5vBErWXbWsR85aNFbgZG5V9oxYAciTROFqk2aLpZw2pLsn5o1HnCkdpV PPL2S63Sa5qaIq+Tdiuij5qTjzQhsR74a3A+20kyE1GOEVWFOLePDOeGLR+V6XqYec9p HI6AtNzB9IgClYiO1Jyjq21rlvQJBx+iCnaOBLtFzY05P1qlADlLIzk7e8gvHrou3YtV 2Bmw== X-Forwarded-Encrypted: i=1; AJvYcCXJV9pgYOa8has+LwVk8A6r3tq27bouIX+X1nd/5DHOzKcdUp0YTvQKVYU3iFeArfke2gGV3ihNqv4eGcde@lists.postgresql.org X-Gm-Message-State: AOJu0YzzrrRhwpbP0tJ3MPMXIb1Xh+O/8n74FXJJCStnWkQtAr1j7R04 QoQUMqdZcHkvMv6IBxPUbndmqRTnJNecQFZ/xJWHTNVeD7nU1QVzlBb7yY1erWehRCYvgqyapSD GFmCwrJgMldxQdnuGMf1eZtDPlxbraVo= X-Gm-Gg: ATEYQzy0hOFJm6ee5v8sqwnceXQlpNh4a1USzHoz2bFSBZEXci3NTJR7kCY9J8iCKr7 3PNn5y3XSQAlYAzDKsk1SzdEFkqNpCnKDtAsjNydY0IO63XaaIi1b5PjV9hsXg2BCicmjrgo954 QIShjpQo5oqHAKhoqeejRBb/B1EO7/ELWM4bkjhdnRXm0mHqXkoEIt6YORqor/291ckH5ucd8rF FhCq3Q6G0CH1Mk5r37zutYkMtU4ODQX8A+YUjDSAARDD26ywyFP/3eTEyrKDtxGsPjbE6HXZlwX T1Vuk/gNEZnX/eG9uFiIbgpk9Hb2FC+0Apvh8+oVw7SpghkjnXg= X-Received: by 2002:a05:6820:151b:b0:67b:b4f4:2744 with SMTP id 006d021491bc7-67bc8895e80mr2144353eaf.17.1773247194904; Wed, 11 Mar 2026 09:39:54 -0700 (PDT) MIME-Version: 1.0 References: <6eff5e43-cacd-4a2a-ad1d-e3b313c86050@uni-muenster.de> <950BB7B5-0180-4C36-82A0-7E17B920F740@gmail.com> <8ECD9403-F0BB-4971-94CF-2709EEB4E3B9@gmail.com> <9174F0CF-2F70-4B4F-AED4-CAF113B7F093@gmail.com> <14669a83-c7b4-4cdf-890c-dceecd025ee1@uni-muenster.de> <3F59D90E-9A47-4C1C-B330-D62D668A462E@gmail.com> <5e01263a-1994-44d5-9e98-7212acf9c985@uni-muenster.de> In-Reply-To: From: Greg Sabino Mullane Date: Wed, 11 Mar 2026 12:39:19 -0400 X-Gm-Features: AaiRm51LiPYoIOw_9nGKfafkI5-8rlXqIY6Z5iIOw2bT_r9eg9Tb3Fhqi6hlQVA Message-ID: Subject: Re: ALTER TABLE: warn when actions do not recurse to partitions To: Chao Li Cc: Jim Jones , "David G. Johnston" , Postgres hackers Content-Type: multipart/alternative; boundary="00000000000026be43064cc24934" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000026be43064cc24934 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 11, 2026 at 3:05=E2=80=AFAM Chao Li wr= ote: > Are you concerning that rendering the full message text is the extra work= ? > This is not a hot path, so I don=E2=80=99t think that would be a big deal= . > Actually, adding two more fields sounds more expensive Well, the recurring creation and freeing of the strings is the part that seems inefficient. But you don't even need to store the strings at all if you are tracking the action+rel. In such a case, the final strings can be created on the fly inside of EmitPartitionNoRecurseNotice, right? Then you just need a list to store the combos of action+relation. Yes, as SET SCHEMA doesn=E2=80=99t go through the standard ALTER TABLE proc= ess: > AlterTable() -> ATController() -> ATPrepCmd(). > > If you get some idea, please let me know. > Nothing worth the trouble, to be honest. As you rightly pointed out, this is not a hot path. Cheers, Greg --00000000000026be43064cc24934 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 11, 2026 at = 3:05=E2=80=AFAM Chao Li <li.evan.chao@gmail.com> wrote:
Are you concernin= g that rendering the full message text is the extra work? This is not a hot= path, so I don=E2=80=99t think that would be a big deal. Actually, adding = two more fields sounds more expensive

Well,= the recurring creation and freeing of the strings is the part that seems i= nefficient. But you don't even need to store the strings at all if you = are tracking the action+rel. In such a case, the final strings can be creat= ed on the fly inside of=C2=A0EmitPartitionNoRecurseNotice, right? Then you = just need a list to store the combos of action+relation.

Yes, as SET SCHEMA does= n=E2=80=99t go through the standard ALTER TABLE process: AlterTable() ->= ATController() -> ATPrepCmd().

If you get some idea, please let me know.

Nothing worth the trouble, to be honest. As you rightly pointed out, thi= s is not a hot path.


Cheers,
Greg<= /div>

--00000000000026be43064cc24934--