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 1sp6V7-00GaJC-7R for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Sep 2024 13:38:18 +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 1sp6V6-002z1U-FT for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Sep 2024 13:38:16 +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 1sp6V5-002z0s-Qt for pgsql-hackers@lists.postgresql.org; Fri, 13 Sep 2024 13:38:16 +0000 Received: from relay2-d.mail.gandi.net ([217.70.183.194]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sp6Uy-000yGf-1I for pgsql-hackers@lists.postgresql.org; Fri, 13 Sep 2024 13:38:13 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 3E9B34000B; Fri, 13 Sep 2024 13:38:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=postgresfriends.org; s=gm1; t=1726234685; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uTv/1LE2gnuEs2V6dF18eFje6rinBhmx0cMxMKzR8VE=; b=OBYSdWBfPqIpEdQ+T1/tnijndtg8cwwub7J7yW18Z0sNvsFv+edXOjUnCfl2FmbHvLAasr E2CuYE+58SgXTyzrn4Ak6pWVUSBFsA2UmDOC0DN5ZxwkBfEGywSxSX/wpyYPnNuW+idg/F UfYCyDQhb+jWw2n0HMs0aX0GnzUtU9x4lQiU+kkOHRkVpCHkQSFXuGtC04sPjlBAqXgndC su4QzSafOgz7ByePKmx3MteCu1s0oz0N44sSTAkIieHHnKZOOwhaYbvIYN9FVGeQaOHT2L SmV02ZjGZ+zdxkUm9KQHSIMfURFti3FwYc5yC/GKWE3M6DGqWGDrloApXqv11A== Message-ID: <15a193c9-e1e8-4ec3-a1b0-8179603bf859@postgresfriends.org> Date: Fri, 13 Sep 2024 15:38:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Mutable foreign key constraints To: Andreas Karlsson , Laurenz Albe , Tom Lane , pgsql-hackers@lists.postgresql.org References: <4162598.1726176826@sss.pgh.pa.us> <560b5873c9b8129a4b7b4fe3239ec32363168599.camel@cybertec.at> <7c9f8c8b-e5ca-4675-bc1c-f27789059ee7@proxel.se> From: Vik Fearing Content-Language: en-US In-Reply-To: <7c9f8c8b-e5ca-4675-bc1c-f27789059ee7@proxel.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-GND-Sasl: vik@postgresfriends.org List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 9/13/24 15:05, Andreas Karlsson wrote: > On 9/13/24 4:41 AM, Laurenz Albe wrote: >> That's very broken and should not be allowed. > > +1 > >>> A possible objection is that if anybody has such a setup and >>> hasn't noticed a problem because they never change their >>> timezone setting, they might not appreciate us breaking it. >> >> I hope that there are few cases of that in the field, and I think it >> is OK to break them.  After all, it can be fixed with a simple >> >>    ALTER TABLE foo ALTER id TYPE timestamptz; >> >> If the session time zone is UTC, that wouldn't even require a rewrite. >> >> I agree that it cannot be backpatched. > > I unfortunately suspect there might be more cases than we think in the > field due to many people not understanding the difference between > timestamp and timestamptz but the good thing is that > timestamp/timestamptz are rare in foreign keys, even in composite ones. It will become a lot more common with WITHOUT OVERLAPS, so I think it is important to fix this at the same time or earlier as that feature. > Since this is quite broken and does not have any real world usefulness I > think we should just go ahead and disallow it and have a few people > complain. +1 -- Vik Fearing