On 27 April 2015 at 17:33, Stephen Frost wrote:
> Dean,
>
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> I took another look at this and came up with some alternate comment
>> rewording. I also added a couple of additional comments that should
>> hopefully clarify the code a bit.
>
> Finall
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> I took another look at this and came up with some alternate comment
> rewording. I also added a couple of additional comments that should
> hopefully clarify the code a bit.
Finally got back to this. Made a few additional changes that made
I took another look at this and came up with some alternate comment
rewording. I also added a couple of additional comments that should
hopefully clarify the code a bit.
Regards,
Dean
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
new file mode 100644
in
On 1 March 2015 at 18:23, Stephen Frost wrote:
>> Thanks. Do you want me to post an update, or are you going to hack on it?
>
> Either works for me, though I'm happy to handle the modifications to
> this if it means you have time to look at the other patches.. :)
>
OK, I'll continue testing the o
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> Thanks for looking at this.
Thanks for working on it. :)
> On 28 February 2015 at 04:25, Stephen Frost wrote:
> > * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> >> --- 1318,1347
> >> }
> >>
> >>
> >> /***
Thanks for looking at this.
On 28 February 2015 at 04:25, Stephen Frost wrote:
> Dean,
>
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> Attached is a patch that does that, allowing restriction clause quals
>> to be pushed down into subquery RTEs if they contain leaky functions,
>> provided
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> Attached is a patch that does that, allowing restriction clause quals
> to be pushed down into subquery RTEs if they contain leaky functions,
> provided that the arglists of those leaky functions contain no Vars
> (such Vars would necessaril
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Robert Haas wrote:
> > On Wed, Jan 14, 2015 at 9:22 AM, Dean Rasheed
> > wrote:
> > > On 14 January 2015 at 13:29, Robert Haas wrote:
> > >> One thing they could still leak is the number of times they got
> > >> called, and thus possibly the n
Robert Haas wrote:
> On Wed, Jan 14, 2015 at 9:22 AM, Dean Rasheed
> wrote:
> > On 14 January 2015 at 13:29, Robert Haas wrote:
> >> One thing they could still leak is the number of times they got
> >> called, and thus possibly the number of unseen rows. Now if the
> >> expressions get constant
On Wed, Jan 14, 2015 at 9:22 AM, Dean Rasheed wrote:
> On 14 January 2015 at 13:29, Robert Haas wrote:
>> One thing they could still leak is the number of times they got
>> called, and thus possibly the number of unseen rows. Now if the
>> expressions get constant-folded away that won't be an is
On 14 January 2015 at 13:29, Robert Haas wrote:
> One thing they could still leak is the number of times they got
> called, and thus possibly the number of unseen rows. Now if the
> expressions get constant-folded away that won't be an issue, but a
> clever user can probably avoid that.
>
Right
On Fri, Jan 9, 2015 at 7:54 AM, Dean Rasheed wrote:
> A while ago [1] I proposed an enhancement to the way qual pushdown
> safety is decided in RLS / security barrier views. Currently we just
> test for the presence of leaky functions in the qual, but it is
> possible to do better than that, by fu
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> A while ago [1] I proposed an enhancement to the way qual pushdown
> safety is decided in RLS / security barrier views. Currently we just
> test for the presence of leaky functions in the qual, but it is
> possible to do better than that, by
13 matches
Mail list logo
