Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pUnn9-0008Db-Hs for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Feb 2023 12:00:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pUnn8-0005Wz-6y for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Feb 2023 12:00:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pUnn7-0005Wp-U6 for pgsql-bugs@lists.postgresql.org; Wed, 22 Feb 2023 12:00:09 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pUnn2-0002BM-ED for pgsql-bugs@lists.postgresql.org; Wed, 22 Feb 2023 12:00:09 +0000 Received: by mail-lj1-x235.google.com with SMTP id a30so7632030ljr.0 for ; Wed, 22 Feb 2023 04:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YNzw3EyTp93BCv0ZusjcoNFM4p6vmWPv5A3EhC+x6sc=; b=pWyK76DlwEp1NZIUdd5JAYDSKtBD1CyaC48sYYXK0lgYfxyeiavtug+iWm1XYYPtE6 7yF7GPlODWeVmqGPR+6y/FPZB0fwD+v0hF/a7357okWXuVUKqLxHGJhvhT5rgakNYQsl k8Y4aHNgC5o0nnj6qe08zOMa+2rW68OpFWNN5mDgpB7RIdVHpzmHbUbtiBXz7FbzqZxZ GVwhme0qSIJ4fv3sKfIKFagUN5ecu/sR4DakqxZwN9PlPQodq8kTAA5cxOqFn8toWqrL whqLGAo11klutACtQ7uNui97i3ML+44RCzhy8t/dLxZeV/dWb33P9TjbapM6tOagZtkn x95w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YNzw3EyTp93BCv0ZusjcoNFM4p6vmWPv5A3EhC+x6sc=; b=cvUBS/h+uudENkFNvInJ2IpOoWTNHZOV6Rt/UEzB56XqARKV6cceb8r/eQDtqjPLrq 0fwlJyN1lCx3qlo3JkWtaHbohMD/g75yCmADAIEFK8SJSDndzeT2GixCCnLsL46NfoKh vOedOPvU/KD5aLSRmMq61EIgfr0k5r1X7poxNUDl4y5c9cEIyci7HuXTjCGmm4YuX/Tc 1QRPaeo2vSnRubi+vfakVEbMBvTP48ioewWEHnWi3Gyh1kJOxWG5/d3LyAXdwpAd+NgG Y614unXEwjV+6FNx9AtdgX4vFhXJMZEKKdHSv4mWTVmbUxKJkaMyGXhj7m0YCSI5oW6+ yPfw== X-Gm-Message-State: AO0yUKUBTJt5XWLRZlq/2v5QnyMRPVNF0S6axesKMEgdGIdgG8fXD+81 hmsOiuv+bI58CpTdnk9S+jc= X-Google-Smtp-Source: AK7set85wwkzyHhh83Ej/gZIugGyyNYnlv747BSs/qRxmYGKeRc9U53EWOGPtxSEBLXdNKx81NdEkg== X-Received: by 2002:a05:651c:1508:b0:293:4e4b:bf5e with SMTP id e8-20020a05651c150800b002934e4bbf5emr4426477ljf.3.1677067202328; Wed, 22 Feb 2023 04:00:02 -0800 (PST) Received: from [1.0.0.7] ([178.155.5.178]) by smtp.gmail.com with ESMTPSA id k23-20020a2e92d7000000b002936037334asm967303ljh.134.2023.02.22.04.00.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Feb 2023 04:00:01 -0800 (PST) Message-ID: <60780f8c-3132-133e-8286-538b732bff19@gmail.com> Date: Wed, 22 Feb 2023 15:00:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values Content-Language: en-US To: Dean Rasheed Cc: Tom Lane , pgsql-bugs@lists.postgresql.org References: <17803-53c63ed4ecb4eac6@postgresql.org> <3953951.1676991950@sss.pgh.pa.us> <3977948.1677002558@sss.pgh.pa.us> <7f8f1bbb-9fb3-80fb-a400-5c7e755b5aa2@gmail.com> From: Alexander Lakhin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 22.02.2023 12:07, Dean Rasheed wrote: > On Wed, 22 Feb 2023 at 08:00, Alexander Lakhin wrote: >> I have a minor question about the condition: >> + if (pt->commandType == CMD_INSERT ... >> Is it possible to get another commandType there? > Yes, there could also be ON INSERT DO ALSO UPDATE/DELETE rules. The > new code is intended to apply only for DO ALSO INSERT .. SELECT rules > (where the VALUES RTE in "pt" isn't in the usual place), but other > types of command in the rule are also possible. As long as the > top-level command is a multi-row INSERT ... VALUES (), (), ... it can > reach this code block. Thanks! I understand this place better now. I mistakenly supposed that VALUES RTE can intervene with INSERT only. But while exploring how they can affect other statements, I've found one more interesting thing: CREATE TABLE t (a int, b int DEFAULT -1); CREATE VIEW v AS SELECT * FROM t; CREATE RULE vr AS ON INSERT TO v DO ALSO INSERT INTO t SELECT NEW.b; INSERT INTO v VALUES(10, -1), (20, DEFAULT); SELECT * FROM v;  a  | b ----+----  10 | -1  20 | -1  -1 | -1     | -1 It seems that a NEW field filled correctly if it is not DEFAULT, but DEFAULT is lost somehow. Best regards, Alexander