Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjYMr-0001c0-Jm for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Sep 2016 21:02:18 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bjYMp-0007jV-GN for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Sep 2016 21:02:15 +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 1bjYMo-0007jP-Or for pgsql-hackers@postgresql.org; Mon, 12 Sep 2016 21:02:15 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bjYMl-0000r7-Vc for pgsql-hackers@postgresql.org; Mon, 12 Sep 2016 21:02:13 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B01F220930; Mon, 12 Sep 2016 17:02:09 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 12 Sep 2016 17:02:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=T7qwK9gCp+nYPjC wkJp8wmlG32o=; b=PPNfnIuQMhuksalKS7OTdqR7FvV6tNF0AZQ8T/b8Fr9+dS0 LFU8qr/RiME6pup3BTPWrKOHIYT9HQDJPNNmQSRJH2rgpzMuhNqwVJFuK3i5sPLm eEE/vF4T+oWbE5hBprEraA1vdo4aWlgMgvibbsovYnQRm+NCp6fCf5HEIOtU= X-Sasl-enc: mPJ4C28axsWMibiq02PsgTHrFgHhoWK28aBxO6VMtUYm 1473714129 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 698F2F2988; Mon, 12 Sep 2016 17:02:09 -0400 (EDT) Subject: Re: identity columns To: Vitaly Burovoy References: <6adbacbf-73bc-dd1a-2033-63409180fd18@2ndquadrant.com> Cc: pgsql-hackers From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <497c40af-bd7a-5cb3-d028-d91434639fe0@2ndquadrant.com> Date: Mon, 12 Sep 2016 17:02:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.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 Thank you for this extensive testing. I will work on getting the bugs fixed. Just a couple of comments on some of your points: On 9/9/16 11:45 PM, Vitaly Burovoy wrote: > It compiles and passes "make check" tests, but fails with "make check-world" at: > test foreign_data ... FAILED I do not see that. You can you show the diffs? > 1. The standard requires "... ALTER COLUMN ... SET GENERATED { ALWAYS > | BY DEFAULT }" (9075-2:2011 subcl 11.20), but the patch implements it > as "... ALTER COLUMN ... ADD GENERATED { ALWAYS | BY DEFAULT } AS > IDENTITY" SET and ADD are two different things. The SET command just changes the parameters of the underlying sequence. This can be implemented later and doesn't seem so important now. The ADD command is not in the standard, but I needed it for pg_dump, mainly. I will need to document this. > 14. It would be fine if psql has support of new clauses. What do you mean by that? Tab completion? > 16. I think it is a good idea to not raise exceptions for "SET > GENERATED/DROP IDENTITY" if a column has the same type of identity/not > an identity. To be consistent with "SET/DROP NOT NULL". These behaviors are per SQL standard. -- 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