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 1sYRqH-00BRhn-7e for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Jul 2024 14:59:17 +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 1sYRqF-000UUC-Nh for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Jul 2024 14:59:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYRqE-000UU3-GX for pgsql-hackers@lists.postgresql.org; Mon, 29 Jul 2024 14:59:15 +0000 Received: from fout3-smtp.messagingengine.com ([103.168.172.146]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYRqA-0025Jh-Pe for pgsql-hackers@postgresql.org; Mon, 29 Jul 2024 14:59:13 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id 1F42C138020F; Mon, 29 Jul 2024 10:59:09 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 29 Jul 2024 10:59:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eisentraut.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm2; t=1722265149; x=1722351549; bh=gVxJC9BeK4RHiBAYb5JQsYp5K9l+iVGD eO0FvIR/Nkk=; b=9euwqdtRrE/JvSH/2N/9tX+Yi2fUi9A+JQYbkxyn8aApzntn 8byrgxYDQXv3fYz4nLCrU0aT4w7UNH7aWnksbViba8r5ABn+DySHN2HqtEE8QMDE 3EvEbEtQth6jf7vndPb4kSRy9n9YwzEuDmKfnfz7S731/FX+dStsgmAh33AXkYsP hzUBO823x13u1VRZblFcFbhEBuJJLhU13oWG2vcLuhzHAezK16Fia+X6uShchZ5t XLmNAVDKLYQQFwNlPe2t0GK9nGIE0HEx5tluJhx1McXFWrYtt63pZ7xwphQ75Lqh lIwq5DrV+fiRvG/Ec0dVhu2Tyewe4FLYWwWDig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1722265149; x= 1722351549; bh=gVxJC9BeK4RHiBAYb5JQsYp5K9l+iVGDeO0FvIR/Nkk=; b=o w8ehN010pADY45mg6pY9iLYTUr00yib/k2qQk/i6/T/D70wIFqBXw9opDfBPyd5B 7CKPAt5ZbQYtVk8bY/4am7ezA9v1khP3yCBDQ0C9pOnYua97Kecpup/dAccbINMQ mbXNMemIdseYDkUnUdfKeN3zBDLDwLA8UxcrQUHqYcH9cuZpCEmLOZwAkhHImqpR kjxR2iaNlNOtqzmzbQTmhC/dQ2Bkf99a8gXjy95Be8siJ9cAP+Vd5jUCu5Wv6aDh llu8xgKVPTLih47788gtyEpqVaLY9CKAw+37JIwzqkeR2WRLE1j6Bg300yiUMkoU nHV+eXIRQ55GI0mpPJKeA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrjedvgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtje ertddtvdejnecuhfhrohhmpefrvghtvghrucfgihhsvghnthhrrghuthcuoehpvghtvghr segvihhsvghnthhrrghuthdrohhrgheqnecuggftrfgrthhtvghrnhepleejtddugffgff efhfeiteefheetudekjeeutdelhfeggfffudejheeufeduffeknecuffhomhgrihhnpehp ohhsthhgrhgvshhqlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehpvghtvghrsegvihhsvghnthhrrghuthdrohhrghdpnhgspghr tghpthhtoheptd X-ME-Proxy: Feedback-ID: ie0a040ee:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 29 Jul 2024 10:59:08 -0400 (EDT) Message-ID: <732a9543-0312-4f0c-a471-857b507a3546@eisentraut.org> Date: Mon, 29 Jul 2024 16:59:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Virtual generated columns To: jian he Cc: pgsql-hackers References: Content-Language: en-US From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 22.07.24 12:53, jian he wrote: > another bug? > drop table gtest12v; > CREATE TABLE gtest12v (a int PRIMARY KEY, b bigint, c int GENERATED > ALWAYS AS (b * 2) VIRTUAL); > insert into gtest12v (a,b) values (11, 22147483647); > table gtest12v; > > insert ok, but select error: > ERROR: integer out of range > > should insert fail? I think this is the correct behavior. There has been a previous discussion: https://www.postgresql.org/message-id/2e3d5147-16f8-af0f-00ab-4c72cafc896f%402ndquadrant.com > CREATE TABLE gtest12v (a int PRIMARY KEY, b bigint, c int GENERATED > ALWAYS AS (b * 2) VIRTUAL); > CREATE SEQUENCE sequence_testx OWNED BY gtest12v.c; > > seems to work. But I am not sure if there are any corner cases that > make it not work. > just want to raise this issue. I don't think this matters. You can make a sequence owned by any column, even if that column doesn't have a default that invokes the sequence. So nonsensical setups are possible, but they are harmless.