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 1q7sXb-0002QM-8N for pgsql-hackers@arkaria.postgresql.org; Sat, 10 Jun 2023 06:57:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q7sXa-00011d-13 for pgsql-hackers@arkaria.postgresql.org; Sat, 10 Jun 2023 06:57:38 +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 1q7sXZ-0000zt-LO for pgsql-hackers@lists.postgresql.org; Sat, 10 Jun 2023 06:57:37 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1q7sXW-001DLw-VS for pgsql-hackers@postgresql.org; Sat, 10 Jun 2023 06:57:36 +0000 Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-25665d2a8bdso1055507a91.0 for ; Fri, 09 Jun 2023 23:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686380254; x=1688972254; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qr+s7mKaemedyv/SNCq5kqdAmXCrhmglGXoIVZ94rHs=; b=qLYWwd15CoZiUekgQ3cLllVNbpbOwjtYay2ld2IkXdx/oPCOK4d7y5m/Xls98uKEQS ROWKNFvYx9SWSm8naoZUYKRKY7SHUA5T+xvNmDE9rgFl66aUNl50SCP8om8N8+T7L7Fc OFLBnnrmMt9/PI5pZC1oEU52FXC7+ckmEGNo8KtCvy7S7P1yLZkyvGJPJV15QUXXqOey qh4s49NDdmn7WvEN2LkJALNPQF3gKwcT6Jird6N7sQ6cwgbQI6NZ9s7ZJJTB+5aDZ5gD uhw23Z2kJZHmptYteOWCnlsaR4hHdVgfqY/+nc1f5Yjingc3Izsoo8q7XmbOz+EthvmE 4jjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686380254; x=1688972254; 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=qr+s7mKaemedyv/SNCq5kqdAmXCrhmglGXoIVZ94rHs=; b=S6lgeE+nreDKlk+asz6P7JbSxqKhljhSs3nyhOyI4hDyCgxma1u/S86mFuZo7gVQo5 tdcxH7PuanXsXT5zXJ+NotSNjaeOnqxaJ0hp2zYtwIJmO/PhBkTCjvHeH4Q/PdKrEJiV s0c1eD94lMEs33rRZBbEVzBiO9pjotKyWXC5VdbVAoItV+zNETD0NQzDo6Lvwig6E7Wd wBDMWGGY0ezIxS1QdPDPukwKmmRHU7BipMuIHLllMrF48FhMex1ef2LHmS3rCUQfGDnV MHIoB/XXqYLNXyrZ22y7lgp1458/j9UdO5ktgjCwK6VVtcrFZQfc+LPJb+KG+ZHE+g3D CWAA== X-Gm-Message-State: AC+VfDzgHl/3o0wYz/esnDbA0nPAuotKUFcLP58qpBKi9Xm4Tm85phs+ JVCJAGcjLp55I22F65f8M9jF2B/aYEWrGqM82d4= X-Google-Smtp-Source: ACHHUZ58NwPDaIazaxGfKXFVxe39FyWh6yj75NPdJKPglSqBK0rCcfFBM+3RS6dZfl8BlgK2A74e+ReSc3ekead6sPg= X-Received: by 2002:a17:90b:4f47:b0:259:3cf1:a47b with SMTP id pj7-20020a17090b4f4700b002593cf1a47bmr2770353pjb.29.1686380253460; Fri, 09 Jun 2023 23:57:33 -0700 (PDT) MIME-Version: 1.0 References: <3953179e-9540-e5d1-a743-4bef368785b0@pgmasters.net> <462cd5de-3ade-989b-0798-7e1cab562991@pgmasters.net> <470644.1686327286@sss.pgh.pa.us> In-Reply-To: From: Amit Langote Date: Sat, 10 Jun 2023 15:57:22 +0900 Message-ID: Subject: Re: Views no longer in rangeTabls? To: David Steele Cc: Pg Hackers , Tom Lane Content-Type: multipart/alternative; boundary="000000000000f6bb1f05fdc0fffa" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f6bb1f05fdc0fffa Content-Type: text/plain; charset="UTF-8" On Sat, Jun 10, 2023 at 15:51 David Steele wrote: > On 6/9/23 19:14, Tom Lane wrote: > > David Steele writes: > >> Thank you, this was very helpful. I am able to get the expected result > >> now with: > > > >> /* We only care about tables/views and can ignore subqueries, etc. */ > >> if (!(rte->rtekind == RTE_RELATION || > >> (rte->rtekind == RTE_SUBQUERY && OidIsValid(rte->relid)))) > >> continue; > > > > Right, that matches places like add_rtes_to_flat_rtable(). > > Good to have confirmation of that, thanks! > > >> One thing, though, rte->relkind is not set for views, so I still need to > >> call get_rel_relkind(rte->relid). Not a big deal, but do you think it > >> would make sense to set rte->relkind for views? > > > > If you see "rte->rtekind == RTE_SUBQUERY && OidIsValid(rte->relid)", > > it's dead certain that relid refers to a view, so you could just wire > > in that knowledge. > > Yeah, that's a good trick. Even so, I wonder why relkind is not set when > relid is set? I too have been thinking that setting relkind might be a good idea, even if only as a crosscheck that only view relations can look like that in the range table. > -- Thanks, Amit Langote EDB: http://www.enterprisedb.com --000000000000f6bb1f05fdc0fffa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 10, 2023 at 15:51 David Steele <david@pgmasters.net> wrote:
On 6/9/23 19:14, Tom Lane wr= ote:
> David Steele <david@pgmasters.net> writes:
>> Thank you, this was very helpful. I am able to get the expected re= sult
>> now with:
>
>> /* We only care about tables/views and can ignore subqueries, etc.= */
>> if (!(rte->rtekind =3D=3D RTE_RELATION ||
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (rte->rtekind =3D=3D RTE_SUBQUERY &a= mp;& OidIsValid(rte->relid))))
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0continue;
>
> Right, that matches places like add_rtes_to_flat_rtable().

Good to have confirmation of that, thanks!

>> One thing, though, rte->relkind is not set for views, so I stil= l need to
>> call get_rel_relkind(rte->relid). Not a big deal, but do you th= ink it
>> would make sense to set rte->relkind for views?
>
> If you see "rte->rtekind =3D=3D RTE_SUBQUERY && OidIsV= alid(rte->relid)",
> it's dead certain that relid refers to a view, so you could just w= ire
> in that knowledge.

Yeah, that's a good trick. Even so, I wonder why relkind is not set whe= n
relid is set?

I t= oo have been thinking that setting relkind might be a good idea, even if on= ly as a crosscheck that only view relations can look like that in the range= table.
--
Thanks, A= mit Langote
EDB: http://www.enterprisedb.com
--000000000000f6bb1f05fdc0fffa--