Re: API change advice: Passing plan invalidation info from the rewriter into the planner? - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: API change advice: Passing plan invalidation info from the rewriter into the planner? |
Date | |
Msg-id | CA+TgmobKYTQA+MHCNi8v8Q7tVSgZjXJD3DhpaJ1m_42bqHocUw@mail.gmail.com Whole thread Raw |
In response to | Re: API change advice: Passing plan invalidation info from the rewriter into the planner? (Gregory Smith <gregsmithpgsql@gmail.com>) |
Responses |
Re: API change advice: Passing plan invalidation info from
the rewriter into the planner?
(Stephen Frost <sfrost@snowman.net>)
Re: API change advice: Passing plan invalidation info from the rewriter into the planner? ("Brightwell, Adam" <adam.brightwell@crunchydatasolutions.com>) |
List | pgsql-hackers |
On Thu, Jun 12, 2014 at 6:33 PM, Gregory Smith <gregsmithpgsql@gmail.com> wrote: > I'm kind of surprised to see this turn into a hot button all of the sudden > though, because my thought on all that so far has been a giant so what? > This is what PostgreSQL does. [...] > But let's not act like RLS is a scary bogeyman because it introduces a new > way to hack the server or get surprising side-effects. That's expected and > possibly unavoidable behavior in a feature like this, and there are much > worse instances of arbitrary function risk throughout the core code already. I have some technical comments on later emails in this thread, but first let me address this point. In the past, people have sometimes complained that reviewers waited until very late in the cycle to complain about issues which they found problematic. By the time the issues were pointed out, insufficient time remained before feature freeze to get those issues addressed, causing the patch to slip out of the release and provoking developer frustration. It has therefore been requested numerous times by numerous people that potential issues be raised as early as possible. The concerns that I have raised in this thread are not new; I have raised them before. However, we are now at the beginning of a new development cycle, and it seems fair to assume that the people who are working on this patch are hoping very much that something will get committed to 9.5. Since it seems to me that there are unaddressed issues with the design of this patch, I felt that it was a good idea to make sure that those concerns were on the table right from the beginning of the process, rather than waiting until the patch was on the verge of commit or, indeed, already committed. That is why, when this thread was revived on June 10th, I decide that it was a good time to again comment on the design points about which I was concerned. After sending that one (1) email, I was promptly told that "I'm very disappointed to hear that the mechanical pieces around making RLS easy for users to use ... is receiving such push-back." The push-back, at that point in time, consisted of one (1) email. Several more emails have been sent that time, including the above-quoted text, seeming to me to imply that the people who are concerned about this feature are being unreasonable. I don't believe I am the only such person, although I may be the main one right at the moment, and you may not be entirely surprised to hear that I don't think I'm being unreasonable. I will admit that my initial email may have contained just a touch of hyperbole. But I won't admit to more than a touch, and frankly, I think it was warranted. I perfectly well understand that people really, really, really want this feature, and if I hadn't understood that before, I certainly understand it now. However, I believe that there has been a lack of focus in the development of the patch thus far in a couple of key areas - first in terms of articulating how it is different from and better than a writeable security barrier view, and second on how to manage the security and operational aspects of having a feature like this. I think that the discussion subsequent to my June 10th email has let to some good discussion on both points, which was my intent, but I still think much more time and thought needs to be spent on those issues if we are to have a feature which is up to our usual standards. I do apologize to anyone who interpreted that initial as a pure rant, because it really wasn't intended that way. Contrariwise, I hope that the people defending this patch will admit that the issues I am raising are real and focus on whether and how those concerns can be addressed. Thanks, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: