From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17872: Dropping an attribute of a composite type breaks
 indexes over the type silently
In-reply-to: <17872-d0fbb799dc3fd85d@postgresql.org>
References: <17872-d0fbb799dc3fd85d@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 27 Mar 2023 10:00:01 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3169549.1679928579.1@sss.pgh.pa.us>
Date: Mon, 27 Mar 2023 10:49:39 -0400
Message-ID: <3169550.1679928579@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3169550.1679928579%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The following script:
> CREATE TYPE ctype AS (i int, j int);
> CREATE TABLE ctbl(a int, cf ctype);
> CREATE UNIQUE INDEX ctbl_idx ON ctbl(cf); 
> INSERT INTO ctbl VALUES (1, '(1, 2)'::ctype), (2, '(1, 1)'::ctype);
> ALTER TYPE ctype DROP ATTRIBUTE j;

> Results in the UNIQUE constraint broken:
> SELECT ctid, * FROM ctbl;
>  ctid  | a | cf  
> -------+---+-----
>  (0,1) | 1 | (1)
>  (0,2) | 2 | (1)

Meh.  I'm happy to classify this as "so don't do that".
The cost of having ALTER TYPE detect such situations seems
vastly out of proportion to the value (and I think it'd
be impossible to prevent race conditions in the detection
anyway).

			regards, tom lane