Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cqUiz-00053r-Oo for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Mar 2017 01:06:06 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cqUiz-0003vT-2Y for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Mar 2017 01:06:05 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cqUhS-00007Z-Cs for pgsql-hackers@postgresql.org; Wed, 22 Mar 2017 01:04:30 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cqUhO-0002eP-Qy for pgsql-hackers@postgresql.org; Wed, 22 Mar 2017 01:04:28 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 25FDB209F6; Tue, 21 Mar 2017 21:04:26 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 21 Mar 2017 21:04:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=v6aXJb6lle2ETSkbQEsT48eVs5uqXBbtRUKCNt9n6AE=; b=VsyhzyFS Hu0kZoqABxKx1BMlMKpg3xwdWdA+47cSVBNAkzsVAIMPreB9e+98ohEVTVHc01CV qLRRaRHGCMlwBWkLkPDGPjuwXXiRwbvYDBOs8wdzIOgpL5YoYNQ9LVTyccuA3xgc 6SvEVnh/tZ7EyktY5ozRqoTbbar46+d80f23BXtLGaMTH9Hg8OiFcj/Tlu+ehplj vFZOjvGq409n4Rabtm0cMbbfsydVDUqpQd62Edi1gU11XvGRor5qUedGGaVPtkGl qJx00PhMKxFrm6mhI9LM9C3Bjq988MfADeOQWg8Jskmf4pXC6BAa1geRIdy2o3ZB EnSAxsuv6kJCHQ== X-ME-Sender: X-Sasl-enc: dRyM72JNw4p1IFRtxexUE44SmTKWtmIAER2D9Zhb3jKF 1490144665 Received: from april.local (c-73-13-66-39.hsd1.pa.comcast.net [73.13.66.39]) by mail.messagingengine.com (Postfix) with ESMTPA id BE3F57E273; Tue, 21 Mar 2017 21:04:25 -0400 (EDT) Subject: Re: identity columns To: Vitaly Burovoy References: <6adbacbf-73bc-dd1a-2033-63409180fd18@2ndquadrant.com> <4ef801f2-64ce-1a58-277d-d9389ae7770d@2ndquadrant.com> <1cf308b6-4f5c-05ba-cc74-0a7121603fcf@2ndquadrant.com> Cc: pgsql-hackers From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Tue, 21 Mar 2017 21:04:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 3/21/17 16:11, Vitaly Burovoy wrote: > I've just checked and still get an error about a type, not about > absence of a column: > test=# CREATE TABLE itest3 (a int generated by default as identity, b text); > CREATE TABLE > test=# ALTER TABLE itest3 ALTER COLUMN o ADD GENERATED ALWAYS AS IDENTITY; > ERROR: identity column type must be smallint, integer, or bigint OK, I have a fix. > My argument is consistency. > Since IDENTITY is a property of a column (similar to DEFAULT, NOT > NULL, attributes, STORAGE, etc.), it follows a different rule: it is > either set or not set. If it did not set before, the "SET" DDL "adds" > it, if that property already present, the DDL replaces it. > There is no "ADD" clause in DDLs like "...ALTER table ALTER column..." > (only "SET", "RESET" and "DROP")[2]. > Your patch introduces the single DDL version with "...ALTER column > ADD..." for a property. But it creates a sequence, so it creates state. So mistakes could easily be masked. With my patch, if you do ADD twice, you get an error. With your proposal, you'd have to use SET, and you could overwrite existing sequence state without realizing it. >> It does change the type, but changing the type doesn't change the >> limits. That is a property of how ALTER SEQUENCE works, which was >> separately discussed. > > Are you about the thread[1]? If so, I'd say the current behavior is not good. > I sent an example with users' bad experience who will know nothing > about sequences (because they'll deal with identity columns). > Would it be better to change bounds of a sequence if they match the > bounds of an old type (to the bounds of a new type)? That's an idea, but that's for a separate patch. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers