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 1rkqLE-00Fqig-2Z for pgsql-novice@arkaria.postgresql.org; Thu, 14 Mar 2024 19:02:12 +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 1rkqLC-002QkS-KT for pgsql-novice@arkaria.postgresql.org; Thu, 14 Mar 2024 19:02:11 +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 1rkqLC-002QkJ-Ca for pgsql-novice@lists.postgresql.org; Thu, 14 Mar 2024 19:02:10 +0000 Received: from mail-ot1-x330.google.com ([2607:f8b0:4864:20::330]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rkqL9-004VnI-2O for pgsql-novice@lists.postgresql.org; Thu, 14 Mar 2024 19:02:09 +0000 Received: by mail-ot1-x330.google.com with SMTP id 46e09a7af769-6e53be9e2cdso530002a34.3 for ; Thu, 14 Mar 2024 12:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710442927; x=1711047727; 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=CcYODJx1xnaDJ1GxjCanmRzg9+Fn+EOQUvVG5fp2NHw=; b=R1Ot43zs6e1UBZao9BpDrpCHEi6smq7G3Auae7IxlJmQx0sg1d0IPu3A3aNjfpdVoc KAMaGngMEFvrXcadwZTIHKdKVGnEgu1gh5lMoB+LALGkFTFiby6U6QZMr/h0szv8Ky1D 0qWU0N9qySs2RK+UdAv5TsFjDD9rwGVr4apYiPIPYH1dH1oHalziQmSJQjXe5xz9p0qY wWQnTOygwOB7SX1D79W/huqNd81RQ9GBF9IHoxwEvrCD/RjK4iC5DnrOodznxwwQ7ZAz Xl8NrWU/gj5B/5bu+cHMMVeEQXvclpzDaa9O4lnABPG+t8AIFU3/5QH4c8dZB6inkB6T Kklg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710442927; x=1711047727; 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=CcYODJx1xnaDJ1GxjCanmRzg9+Fn+EOQUvVG5fp2NHw=; b=vEKV24eBr4ZYQgNhew8uNmAAHYrI7kWw231MaICwfSsMI0Mr/6TWA8wrzxo4Dqh8IJ Djg54rtm1O0KwGOI8A5bo6wyve+UAlU4ghFzXzgqQ0Ve+f3U3qGuAtXrIXO4eqNax0XO hcRLV96TWgDVOkTt2mE9jLJivVU1MwErpRU4wODdSZl0khyva9ZzpaYuMvncTzrNHZGQ lcvC240k2+3TqgiJjjucXU/SeZlwV4SYRJm6mkhv3ru7BWxvCtlAbuBgBH12MpP41asS 78yq1RHw/k/JVBw1Z5cJG8TFaX6h/RcDux1hxOG5hlPUEEep17YRQPi+pzebXmdrmdT+ 1B7g== X-Gm-Message-State: AOJu0YwH+kMC6G+R676vDmtbV3lTZtt+SkmLKwDp3RqiQ2AUWJt1YdY9 vMjvzirek35uH6Lf+/o+bBqqoWqQ2RLpoG+QjBWQ8jfKfvppN6uQ+KiMyj6b7zyjMKmUuhAN43r IzUxhloplTLS+KROi+JgdLS83HCMGWhmtYNg= X-Google-Smtp-Source: AGHT+IHi3NF03/C7b4rCFzOkKAk6CMvL1SC2kLt3zqBIsGru0lNBfmHQSMQtzcS8qdSpk6fgnzzmRRrNNMxGwbeDQu0= X-Received: by 2002:a05:6870:6594:b0:21f:1795:7cb0 with SMTP id fp20-20020a056870659400b0021f17957cb0mr3093739oab.21.1710442927450; Thu, 14 Mar 2024 12:02:07 -0700 (PDT) MIME-Version: 1.0 References: <45e27182-8474-4dc5-be7b-adb87041a111@app.fastmail.com> In-Reply-To: <45e27182-8474-4dc5-be7b-adb87041a111@app.fastmail.com> From: "David G. Johnston" Date: Thu, 14 Mar 2024 12:01:30 -0700 Message-ID: Subject: Re: Sharp edge when dropping columns To: Quentin de Metz Cc: pgsql-novice@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000001971b80613a3872e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001971b80613a3872e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 14, 2024 at 11:45=E2=80=AFAM Quentin de Metz = wrote: > > I found this behavior unexpected. > In general it is advisable to rely on documented behaviors rather than expectations. https://www.postgresql.org/docs/current/sql-altertable.html This long-standing behavior seems unlikely to be changed. Preventing the column from being dropped would in any case be the accepted outcome, not leaving an index behind that refers to a column that doesn't exist. David J. --0000000000001971b80613a3872e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 14, 2024 at 11:45=E2=80=AFAM Quentin de Metz &= lt;quentin@de.me.tz> wrote:

I found this behavior unexpected.

In general it is advisable=C2=A0to rely on docu= mented behaviors rather than expectations.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">h= ttps://www.postgresql.org/docs/current/sql-altertable.html

This long-standing behavior seems unlikely to be changed.=C2=A0 = Preventing the column from being dropped would in any case be the accepted = outcome, not leaving an index behind that refers to a column that doesn'= ;t exist.

David J.

--0000000000001971b80613a3872e--