Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOXSy-000859-Hn for pgsql-hackers@arkaria.postgresql.org; Tue, 03 Jan 2017 22:22:00 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cOXSy-0006yD-4g for pgsql-hackers@arkaria.postgresql.org; Tue, 03 Jan 2017 22:22:00 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cOXSx-0006y7-P6 for pgsql-hackers@postgresql.org; Tue, 03 Jan 2017 22:21:59 +0000 Received: from mail-vk0-x22e.google.com ([2607:f8b0:400c:c05::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cOXSu-0002aV-27 for pgsql-hackers@postgresql.org; Tue, 03 Jan 2017 22:21:59 +0000 Received: by mail-vk0-x22e.google.com with SMTP id x186so280263230vkd.1 for ; Tue, 03 Jan 2017 14:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=XY6o1ixQxYYfRvyhoPJ42D6h1DCbfX0PMHHdhMTnIO0=; b=bd6oeCu4lTis9B6hm6WOng2Jmw5wykz3dxTrfnEkVLv8ht8ZBEHNrEFWtc7ZIZcEa5 FuFYzx3yNxjrvUpcW28DNG/Ki4GG3JJw0ozDkfNyrzQ1TVw9Rep6bV0sZzk1PaxQz/YX 3gD3VE2TGXf5yqg/or2yHy4TwOFsioihrnpqFNpTKZiMs12UEAhPGr4vo+SHSj3TYtpd PmOJLn9HSDMTRbkTbkAW2K194VOrE33Qn6RXFctHSSqewf7ye1Xep4xfB+o4s8h2Na8K 66mXI788WfR4xgkaLM70dltDDr5KkxxFR23+x92rACWS861V22H1kqIIumP2FLJ/Hpbs tlgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=XY6o1ixQxYYfRvyhoPJ42D6h1DCbfX0PMHHdhMTnIO0=; b=R5P1ahwgMudwxqmJ8cjYWuziwAcANEIQEVLMUxxhA4mtVwibAOFuktNmb/ILuESF6C tijIlpvnDXm0jHjsHOQyQFu7H9my5Nz25A3g+8QmU+5WdqcBqHlgGfHi509IxU+mnjWw dADnret+y1QhmIN6fEpb+4od3gvle8RsBixZO6Te+zs734RJeo5ohoH6+f34FJsbZ32d zllUPv+5XobvDzoVpgx8aeVRe4hg5ivWpsuqNXgdUENk8OEZpXGJHS/PLenaoV+89erR GWMH0kiYST4O0l4RtzAbO8Zp2S7gm089IneodQZ7RjoPzozofZ9UhDtt/NNLkcniJMXH UDGA== X-Gm-Message-State: AIkVDXIvWjGcVMNr79Kb1vao6jjhyTnNOEI1nlRiGCpKA/m51LNWe6h145lkNHMQMbNB2dyn X-Received: by 10.31.99.193 with SMTP id x184mr21982843vkb.161.1483482114101; Tue, 03 Jan 2017 14:21:54 -0800 (PST) Received: from alvin.alvh.no-ip.org ([186.9.131.6]) by smtp.gmail.com with ESMTPSA id l94sm21560810ual.9.2017.01.03.14.21.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 14:21:53 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id B1FDD1376; Tue, 3 Jan 2017 19:21:49 -0300 (CLST) Date: Tue, 3 Jan 2017 19:21:49 -0300 From: Alvaro Herrera To: Tom Lane Cc: Justin Pryzby , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type Message-ID: <20170103222149.azbla6jtpnh2ublg@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12279.1483480004@sss.pgh.pa.us> User-Agent: NeoMutt/20161104 (1.7.1) 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 Tom Lane wrote: > A little bit of "git bisect"-ing later, the blame is pinned on > > commit 9550e8348b7965715789089555bb5a3fda8c269c > Author: Alvaro Herrera > Date: Fri Apr 3 17:33:05 2015 -0300 > > Transform ALTER TABLE/SET TYPE/USING expr during parse analysis > > This lets later stages have access to the transformed expression; in > particular it allows DDL-deparsing code during event triggers to pass > the transformed expression to ruleutils.c, so that the complete command > can be deparsed. > > This shuffles the timing of the transform calls a bit: previously, > nothing was transformed during parse analysis, and only the > RELKIND_RELATION case was being handled during execution. After this > patch, all expressions are transformed during parse analysis (including > those for relkinds other than RELATION), and the error for other > relation kinds is thrown only during execution. So we do more work than > before to reject some bogus cases. That seems acceptable. > > Of course, the reason why this work was postponed until execution was > exactly because we wanted to do it over again for each child table. > > We could probably fix the specific issue being seen here by passing the > expression tree through a suitable attno remapping, Hmm, ouch. I can look into fixing this starting tomorrow afternoon. > but I am now filled with dread about how much of the event trigger > code may be naively supposing that child tables have the same attnums > as their parents. I guess it's on me to figure that out. -- Álvaro Herrera https://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