Re: Views no longer in rangeTabls?

2023-06-14 Thread David Steele
On 6/14/23 12:51, Amit Langote wrote: Ah, did think it might be moderation.  Thanks for the confirmation, Michael. It’s out now: https://www.postgresql.org/message-id/E1q9Gms-001h5g-8Q%40gemulon.postgresql.org

Re: Views no longer in rangeTabls?

2023-06-14 Thread Amit Langote
On Wed, Jun 14, 2023 at 15:49 Amit Langote wrote: > On Wed, Jun 14, 2023 at 15:44 Michael Paquier wrote: > >> On Wed, Jun 14, 2023 at 02:34:56PM +0900, Amit Langote wrote: >> > This being my first commit, I intently looked to check if everything’s >> set >> > up correctly. While it seemed to hav

Re: Views no longer in rangeTabls?

2023-06-13 Thread Amit Langote
On Wed, Jun 14, 2023 at 15:44 Michael Paquier wrote: > On Wed, Jun 14, 2023 at 02:34:56PM +0900, Amit Langote wrote: > > This being my first commit, I intently looked to check if everything’s > set > > up correctly. While it seemed to have hit gitweb and GitHub, it didn’t > > pgsql-committers for

Re: Views no longer in rangeTabls?

2023-06-13 Thread Michael Paquier
On Wed, Jun 14, 2023 at 02:34:56PM +0900, Amit Langote wrote: > This being my first commit, I intently looked to check if everything’s set > up correctly. While it seemed to have hit gitweb and GitHub, it didn’t > pgsql-committers for some reason. It seems to me that the email of pgsql-committers

Re: Views no longer in rangeTabls?

2023-06-13 Thread Amit Langote
On Wed, Jun 14, 2023 at 12:08 Amit Langote wrote: > On Tue, Jun 13, 2023 at 9:40 PM David Steele wrote: > > On 6/13/23 11:38, Amit Langote wrote: > > > On Tue, Jun 13, 2023 at 6:33 PM Alvaro Herrera < > alvhe...@alvh.no-ip.org> wrote: > > >> Note that you changed one comment from "permission che

Re: Views no longer in rangeTabls?

2023-06-13 Thread Amit Langote
On Tue, Jun 13, 2023 at 9:40 PM David Steele wrote: > On 6/13/23 11:38, Amit Langote wrote: > > On Tue, Jun 13, 2023 at 6:33 PM Alvaro Herrera > > wrote: > >> Note that you changed one comment from "permission checks" to > >> "permission hecks". > > > > Oops, thanks for pointing that out. > > >

Re: Views no longer in rangeTabls?

2023-06-13 Thread David Steele
On 6/13/23 11:38, Amit Langote wrote: On Tue, Jun 13, 2023 at 6:33 PM Alvaro Herrera wrote: Note that you changed one comment from "permission checks" to "permission hecks". Oops, thanks for pointing that out. Fixed in the attached. I have done another (more careful) review of the comments

Re: Views no longer in rangeTabls?

2023-06-13 Thread Amit Langote
On Tue, Jun 13, 2023 at 6:33 PM Alvaro Herrera wrote: > Note that you changed one comment from "permission checks" to > "permission hecks". Oops, thanks for pointing that out. Fixed in the attached. -- Thanks, Amit Langote EDB: http://www.enterprisedb.com v3-0001-Retain-relkind-too-in-RTE_SU

Re: Views no longer in rangeTabls?

2023-06-13 Thread Alvaro Herrera
Note that you changed one comment from "permission checks" to "permission hecks". -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "No nos atrevemos a muchas cosas porque son difíciles, pero son difíciles porque no nos atrevemos a hacerlas" (Séneca)

Re: Views no longer in rangeTabls?

2023-06-13 Thread David Steele
On 6/13/23 10:27, Amit Langote wrote: On Tue, Jun 13, 2023 at 4:44 PM David Steele wrote: I decided to go with the following because I think it is easier to read: /* We only care about tables/views and can ignore subqueries, etc. */ if (!(rte->rtekind == RTE_RELATION || (rte->rtekind

Re: Views no longer in rangeTabls?

2023-06-13 Thread Amit Langote
On Tue, Jun 13, 2023 at 4:44 PM David Steele wrote: > On 6/13/23 06:09, Amit Langote wrote: > > On Sat, Jun 10, 2023 at 10:27 PM Tom Lane wrote: > >> Julien Rouhaud writes: > >>> On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: > - rte->relkind = 0; > >> > >>> and also handle tha

Re: Views no longer in rangeTabls?

2023-06-13 Thread David Steele
On 6/13/23 06:09, Amit Langote wrote: On Sat, Jun 10, 2023 at 10:27 PM Tom Lane wrote: Julien Rouhaud writes: On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: - rte->relkind = 0; and also handle that field in (read|out)funcs.c Oh, right. Ugh, that means a catversion bump. I

Re: Views no longer in rangeTabls?

2023-06-12 Thread Amit Langote
On Sat, Jun 10, 2023 at 10:27 PM Tom Lane wrote: > Julien Rouhaud writes: > > On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: > >> - rte->relkind = 0; > > > and also handle that field in (read|out)funcs.c > > Oh, right. Ugh, that means a catversion bump. It's not like > we've never

Re: Views no longer in rangeTabls?

2023-06-10 Thread Tom Lane
Julien Rouhaud writes: > On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: >> - rte->relkind = 0; > and also handle that field in (read|out)funcs.c Oh, right. Ugh, that means a catversion bump. It's not like we've never done that during beta, but it's kind of an annoying cost for a d

Re: Views no longer in rangeTabls?

2023-06-10 Thread Julien Rouhaud
On Sat, Jun 10, 2023 at 08:56:47AM -0400, Tom Lane wrote: > > Well, if we're gonna do it we should do it for v16, rather than > change the data structure twice. It wouldn't be hard exactly: > > /* > * Clear fields that should not be set in a subquery RTE. Note that we > * leave the

Re: Views no longer in rangeTabls?

2023-06-10 Thread Tom Lane
David Steele writes: > On 6/10/23 09:57, Amit Langote wrote: >> 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. > +1. Even better if we can do it for PG16. Well, if we're gonn

Re: Views no longer in rangeTabls?

2023-06-10 Thread David Steele
On 6/10/23 09:57, Amit Langote wrote: On Sat, Jun 10, 2023 at 15:51 David Steele > wrote: On 6/9/23 19:14, Tom Lane wrote: > > If you see "rte->rtekind == RTE_SUBQUERY && OidIsValid(rte->relid)", > it's dead certain that relid refers to a view, so yo

Re: Views no longer in rangeTabls?

2023-06-09 Thread Amit Langote
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->

Re: Views no longer in rangeTabls?

2023-06-09 Thread David Steele
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 && OidIsVali

Re: Views no longer in rangeTabls?

2023-06-09 Thread Tom Lane
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 > cont

Re: Views no longer in rangeTabls?

2023-06-09 Thread David Steele
Hi Amit, On 6/9/23 14:25, Amit Langote wrote: On Fri, Jun 9, 2023 at 17:28 David Steele > wrote: In prior versions of Postgres, views were listed in rangeTabls when ExecutorCheckPerms_hook() was called but in PG16 the views are no longer in this list.

Re: Views no longer in rangeTabls?

2023-06-09 Thread Amit Langote
Hi David, On Fri, Jun 9, 2023 at 17:28 David Steele wrote: > Hackers, > > While updating pgAudit for PG16 I found the following (from our > perspective) regression. > > In prior versions of Postgres, views were listed in rangeTabls when > ExecutorCheckPerms_hook() was called but in PG16 the view

Re: Views no longer in rangeTabls?

2023-06-09 Thread David Steele
On 6/9/23 11:28, David Steele wrote: It seems the thing to do here would be to scan permInfos instead, which works fine except that we also need access to rellockmode, which is only included in rangeTabls. We can add a scan of rangeTabls to get rellockmode when needed and we might be better o

Re: views

2017-12-06 Thread Tom Lane
Andrzej Barszcz writes: > I would be happy when checkRuleResultList in rewriteDefine.c lost so strict > conditions for returning clause. Are there any reasons to have such > restriction for views ? Uh, so that the results of a query that invokes the rule are well-defined? If you think that for y