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 1pMoQo-00082b-TK for pgsql-bugs@arkaria.postgresql.org; Tue, 31 Jan 2023 11:04:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pMoQn-0003Nd-PY for pgsql-bugs@arkaria.postgresql.org; Tue, 31 Jan 2023 11:04:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pMoQn-0003NT-HA for pgsql-bugs@lists.postgresql.org; Tue, 31 Jan 2023 11:04:05 +0000 Received: from mail-oi1-x232.google.com ([2607:f8b0:4864:20::232]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pMoQl-0004uF-Cv for pgsql-bugs@lists.postgresql.org; Tue, 31 Jan 2023 11:04:04 +0000 Received: by mail-oi1-x232.google.com with SMTP id r205so12473604oib.9 for ; Tue, 31 Jan 2023 03:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=O0LhhzGyyPQeq4xpOmMdQEClNTc+PcFZZ7EnbM7hU8Y=; b=I5TWzGLuJM+Y/ALrPB+0Wk5ejIFCy5cH2tZerOodj6nqOhAeZPNgmP0uDg6JNsuBFy eTsKQz3HpnU/Egw1aMvu1EV5EjPyHCuOy0jwmFXR9Ofd6MFWYZRxRZTHBNOvli6fS33d OYiVJo51izalJGZF2eNwnv2qclcKBOhoqTPrVKgHd5XZAV5bxIYhMXqqD2nTCaEcyG+c aP4kQxY/peRcfA9qZLAziNttBW5kC8JrgJQ8Ootk1yd8RNc6MDLRfxX93C40Xcod4D/J VDl+w9ugMwuN24aSwEXLMensou9QfNj0iayTVVwbGAMiiDSODk/xFivqNV5w78Fu3AwF zjqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=O0LhhzGyyPQeq4xpOmMdQEClNTc+PcFZZ7EnbM7hU8Y=; b=2aLvaBVZfPaFIv2wKJEOLPbY6qdXq6ZPTdlqFLF3oYt+VQfD8VRwiUWeIZobFmPRRV nlZMLF2CZLH7N8HLNbUWvacN/EX5331fB9QsTERPd6LksD0Ly8Nv4c+IP4aNLFC0ZF1G HU7NIfwFXzliowDb+fAhyWFm9c8lnYyfliuuFp8ZphzfK/uCP+yIiSeJL1dLYm2mRaDJ uXKhvo+QASqF+V/EsK84im9Oow+bVCuEPUZ17nrEsUGtwYGa8jtltfZ+e2jEPJuuRfNd BZ8IjXO4rS+j0JQcuW6vqStYqeFNwceHg15oMIF7Qk1wxN3Lr5eVL9JmFLfMnpoBSVzF z8sg== X-Gm-Message-State: AFqh2koZXtUeK6vR4LH6zDbmzmmbFGGMBgs97hVXV37bOK3iXdW9TozP saWyW4ktXqdOPjWJzps3VGP3Sr2MVNfqTxpJBAw= X-Google-Smtp-Source: AMrXdXsci5JshmSGGk6KuOHpQR9F+MZ3oITNVe6akMzW8SYzLHZYX6QimVKYZ7YnMk1Q1poIf/wxEmpPdvTEDa2iDXU= X-Received: by 2002:aca:1e07:0:b0:36a:d79d:6b44 with SMTP id m7-20020aca1e07000000b0036ad79d6b44mr3474663oic.265.1675163042858; Tue, 31 Jan 2023 03:04:02 -0800 (PST) MIME-Version: 1.0 References: <17502-281a7aaacfaa872a@postgresql.org> <965990.1675119213@sss.pgh.pa.us> In-Reply-To: <965990.1675119213@sss.pgh.pa.us> From: David Rowley Date: Wed, 1 Feb 2023 00:03:47 +1300 Message-ID: Subject: Re: BUG #17502: View based on window functions returns wrong results when queried To: Tom Lane Cc: Richard Guo , =?UTF-8?Q?Daniel_Farka=C5=A1?= , Magnus Hagander , PostgreSQL mailing lists Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 31 Jan 2023 at 11:53, Tom Lane wrote: > This bug seems to have slipped off the radar screen, but it's still > a bug. I continue to believe that the best fix is to disallow SRFs > in window definitions, and present the trivial patch to do so. I don't really object to doing this, but I'm not convinced that someone else won't eventually come along complaining about us changing this. As far as I'm aware, the behaviour is not wrong today provided you always use the column so that remove_unused_subquery_outputs() does not get rid of it. If we disallow this, then maybe it's worth also giving ourselves a bit more flexibility to make it work correctly in the future should someone come along and convince us we shouldn't have disallowed this. Adjusting expression_returns_set() to pass it the relevant PlannerInfo for the Node might be a good idea. If we change our minds in the future then we could easily then modify expression_returns_set_walker() to have it check if the given WindowFunc's WindowClause has SRFs so that we don't remove the unused WindowFunc subquery columns in remove_unused_subquery_outputs(). I'd have probably gone with this as a master-only fix, but is quite likely you're thinking of something that I'm not. Certainly, the consistency of when SRFs are evaluated is pretty terrible so I understand the desire to disallow the WindowClause SRFs so we have one less thing to get wrong. David