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 1pUk3t-00022K-M7 for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Feb 2023 08:01:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pUk2s-0008UY-G9 for pgsql-bugs@arkaria.postgresql.org; Wed, 22 Feb 2023 08: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 1pUk2s-0008UP-5r for pgsql-bugs@lists.postgresql.org; Wed, 22 Feb 2023 08:00:10 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pUk2m-0008Cp-Ec for pgsql-bugs@lists.postgresql.org; Wed, 22 Feb 2023 08:00:09 +0000 Received: by mail-lf1-x130.google.com with SMTP id w27so8951728lfu.4 for ; Wed, 22 Feb 2023 00: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=gRMhLmDCc1Un18MT762C1fyep89PKTfzg5kZ8siZ1MU=; b=Ah3O1CyU55CGBbMi26uw7KF58mM7O38kRAOks+bbF3M+uqu/TOjilPDvAGUse32kwk jTW8LSsYAXz6oQSpbwmhoMvYpj091FKdqFcWNRbm3/k6Qo7wjeI8anRlc587KrfnDyEr s890xLX/DJ0+2YI15G1BGJFAf1gaFCV3xpsVrTuM3ZSRXrB5L1nD2CKO1FcsCF6CBYk8 SavvPJ7iwW+2yRlRzVhVLa6HW3f0esF8GdynpyKUXeZx1yo+4GwfAwR/JO5DAMY5Ttu8 FN4f7livSKOP8nEXgNqq80c+v3Arc0bckS8Y/QXYxgi96VgvDKf/P+Kv/mWtth9s7Naz Qnzw== 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=gRMhLmDCc1Un18MT762C1fyep89PKTfzg5kZ8siZ1MU=; b=LwTZpSWDufv9bGg1J/5DSgn6m+jEUP6GqkFfPb31VrvrVaIllgcTJ2fSMGKEW2ukM7 jGsMyyssDTWU4ZuWGSL2QStfFR5zyZ5pvdX2I63j3XFNsHlG9XJtKUC3aJmhJ/ykzxwT B+exeX7IDOhBFip4r0WYxdGnW8Qh9rahMEHbcNI06UxKJ2U5PWH4Ny6DybgvASr9DHCp /2He08iNd/RI8s1/brROd01bziiYmTcu8eDxD1KnGwv3p8IMbq4qZmzsWeIVLLkeE3o8 WPF51M/aSBTg55XCNGHVPafKj43G3UuY3k430cRSzyRrIG87h/L59n4tUtbGANTf2acA 2m0g== X-Gm-Message-State: AO0yUKXOJQE7SpU3/3L/JWnlfYCGk8Qs5arYJqTbKeV1Dh8i6+DVbsz6 w4BAHtnxgSmSY6lJ2IJKIDw= X-Google-Smtp-Source: AK7set8bSbu6MtdYgYiCEjF4I7CEVxkJGqhQWDHeKUS3tvTcCGbJBMX28oeKYJ4Bvv2myRJ9JTpk5A== X-Received: by 2002:ac2:5391:0:b0:4dd:995b:e5ef with SMTP id g17-20020ac25391000000b004dd995be5efmr916039lfh.47.1677052803190; Wed, 22 Feb 2023 00:00:03 -0800 (PST) Received: from [1.0.0.7] ([178.155.5.178]) by smtp.gmail.com with ESMTPSA id y19-20020ac24213000000b004cb35b31b96sm2091787lfh.257.2023.02.22.00.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Feb 2023 00:00:02 -0800 (PST) Message-ID: <7f8f1bbb-9fb3-80fb-a400-5c7e755b5aa2@gmail.com> Date: Wed, 22 Feb 2023 11:00:01 +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: Tom Lane , Dean Rasheed Cc: pgsql-bugs@lists.postgresql.org References: <17803-53c63ed4ecb4eac6@postgresql.org> <3953951.1676991950@sss.pgh.pa.us> <3977948.1677002558@sss.pgh.pa.us> From: Alexander Lakhin In-Reply-To: <3977948.1677002558@sss.pgh.pa.us> 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 21.02.2023 21:02, Tom Lane wrote: > Dean Rasheed writes: >> Yeah, that makes sense. Something like this? (I think an elog() is >> probably more useful than an Assert(), if we don't find what we >> expect.) > I think it's fine to leave the checks on parsetree->jointree being > a FromExpr as Asserts, because that's assumed in a lot of places. > Rest of it is OK by me. I have a minor question about the condition: +                if (pt->commandType == CMD_INSERT ... Is it possible to get another commandType there? IIUC, we cant get into         if (defaults_remaining && product_queries != NIL) only for INSERT ... In other words, are there other commands that we expect executing following lines for? values_rte = rt_fetch(values_rte_index, pt->rtable); ... rewriteValuesRTEToNulls(pt, values_rte); (ALSO MERGE is not supported, as I can see) If the (pt->commandType == CMD_INSERT) check is for safety, maybe it should be broader? Thanks for the fix! (My extra testing discovered no new anomalies in this area.) Best regards, Alexander