Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1izAI4-0004tz-PE for pgsql-bugs@arkaria.postgresql.org; Wed, 05 Feb 2020 02:19:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1izAI3-0004MU-Ii for pgsql-bugs@arkaria.postgresql.org; Wed, 05 Feb 2020 02:19:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1izAI2-0004MI-6u for pgsql-bugs@lists.postgresql.org; Wed, 05 Feb 2020 02:19:43 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1izAHy-000253-Qd for pgsql-bugs@lists.postgresql.org; Wed, 05 Feb 2020 02:19:41 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id B91A6460; Tue, 4 Feb 2020 21:19:35 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 04 Feb 2020 21:19:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=jXgYwthgvOIyOK2u1HR6uDntLTv YZqD4tRNee0PbwDM=; b=DAawZgxTgrKiATrbq0VqfsWI3cO27uCVBfVEK+JN9rp t2ZVNWSEA4tQsv9FUUtWXxFN/o5IbWyvDCr01oj2ZQVLEn2RK2q95tRjppS3v607 /YDqlXqo9lkZIEySSyJHyHSlzwT3gpgKSiOhRF0IK3rQKV6/KLOaG29HTyuhTHet uGtZ4BEIhl6m20Fl1YjdyzodCfkazXfzvV6UBLXCr/sPxc8bJOYEf1lh6jAoBTu9 SsAIeGw55oAjPRhfb+apD4EvjjHJqBylNO1GIzFVBQOyJAnIM3/FiwC938es4X70 ahKNs5rTk5u5tX23cISDjq65IB1OPmFTy7CfAVEAojA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jXgYwt hgvOIyOK2u1HR6uDntLTvYZqD4tRNee0PbwDM=; b=gccudCeLsHAHjRGKmBvBak Sq8558zWfZHJAjA6VuYc+j2xLxVUdwEcD0IkPxojGPF5QYCPTD5XV4RkqjrbGsY3 aare3Q5oO8d1570EaTS4K/g/z6zkzG4fEMztHKdc8kzwscKoHUpX1F7jSeiU5JQH z3cB73zVQOeLgbwYpX70Ucts2WMPo+z/hckLCSSoaA5OG8aYxMHJuc+ps1tF8kQo Xza0/4zEnyNxImb5bSb0OOVwTnxbggKf5YTVOlH9913ok7q/utYfDlTLi0+p5sKp 9ohDuD1hoeoz4TmQ3Zn+k8ZdafgiRP0ZiPANjabnlt9MdIrQ9nCPiHIsNaJ1VMaA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrhedtgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttdertd dttddvnecuhfhrohhmpeetnhgurhgvshcuhfhrvghunhguuceorghnughrvghssegrnhgr rhgriigvlhdruggvqeenucfkphepieejrdduiedtrddvudejrddvhedtnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghnughrvghssegrnhgr rhgriigvlhdruggv X-ME-Proxy: Received: from intern.anarazel.de (c-67-160-217-250.hsd1.ca.comcast.net [67.160.217.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 967D33060701; Tue, 4 Feb 2020 21:19:34 -0500 (EST) Date: Tue, 4 Feb 2020 18:19:33 -0800 From: Andres Freund To: Vik Fearing Cc: andrew@tao11.riddles.org.uk, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16242: convert_tuple_* not handling missing values correctly Message-ID: <20200205021933.c4wtkpcx2li3um2k@alap3.anarazel.de> References: <16242-d1c9fca28445966b@postgresql.org> <31edb400-f065-73c4-7b1f-2953ad3413e6@postgresfriends.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31edb400-f065-73c4-7b1f-2953ad3413e6@postgresfriends.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-02-05 03:03:04 +0100, Vik Fearing wrote: > On 04/02/2020 03:24, PG Bug reporting form wrote: > > The following example shows a tuple appearing with NULLs in a column > > declared NOT NULL, because there is a missing default value not being filled > > in. The cause is that convert_tuples_by_name, or more precisely > > check_attrmap_match, thinks that it's enough for the tupdescs to match up as > > regards attnums/names/types, without considering that the source tupdesc > > might have missing values that the destination does not. So it incorrectly > > concludes that no conversion is needed, and the missing values become > > null. > > Here is a quick patch that fixes this on master. Should include a regression test... - Andres