On 2015/03/02 5:28, Stephen Frost wrote:
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
I just spotted a trivial bug in this patch -- in
expand_security_quals() you need to set targetRelation = false inside
the loop, otherwise it will be true for the target relation and all
that follow it.
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> I just spotted a trivial bug in this patch -- in
> expand_security_quals() you need to set targetRelation = false inside
> the loop, otherwise it will be true for the target relation and all
> that follow it.
I've pushed a fix for this.
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 27 February 2015 at 03:10, Etsuro Fujita
> wrote:
> > On 2015/02/26 11:38, Stephen Frost wrote:
> >>
> >> I've pushed an update for this to master and 9.4 and improved the
> >> comments and the commit message as discussed.
> >>
> >> Would be g
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 27 February 2015 at 03:10, Etsuro Fujita
> wrote:
> > On 2015/02/26 11:38, Stephen Frost wrote:
> >>
> >> I've pushed an update for this to master and 9.4 and improved the
> >> comments and the commit message as discussed.
> >>
> >> Would be g
On 27 February 2015 at 03:10, Etsuro Fujita wrote:
> On 2015/02/26 11:38, Stephen Frost wrote:
>>
>> I've pushed an update for this to master and 9.4 and improved the
>> comments and the commit message as discussed.
>>
>> Would be great if you could test and let me know if you run into any
>> issu
On 2015/02/26 11:38, Stephen Frost wrote:
I've pushed an update for this to master and 9.4 and improved the
comments and the commit message as discussed.
Would be great if you could test and let me know if you run into any
issues!
OK, thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-ha
Dean, Etsuro,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 18 February 2015 at 16:22, Stephen Frost wrote:
> > Here's the patch against master. I'm still fiddling with the comment
> > wording and the commit message a bit, but barring objections these
> > patches are what I'm planning to
On 18 February 2015 at 16:22, Stephen Frost wrote:
> Here's the patch against master. I'm still fiddling with the comment
> wording and the commit message a bit, but barring objections these
> patches are what I'm planning to move forward with.
>
Yes, that matches what I had in mind.
While you'
On 2015/02/18 21:44, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/18 7:44, Stephen Frost wrote:
Attached is a patch which should address this. Would love your (or
anyone else's) feedback on it. It appears to address the issue which
you raised and the re
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> On 2015/02/18 7:44, Stephen Frost wrote:
> * The patch applies to the latest head, 'make' passes successfully,
> but 'make check' fails in the rowsecurity test.
Here's the patch against master. I'm still fiddling with the comment
wor
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> On 2015/02/18 7:44, Stephen Frost wrote:
> >Attached is a patch which should address this. Would love your (or
> >anyone else's) feedback on it. It appears to address the issue which
> >you raised and the regression test changes are
On 2015/02/18 7:44, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/11 4:06, Stephen Frost wrote:
I had been trying to work out an FDW-specific way to address this, but I
think Dean's right that this should be addressed in
expand_security_qual(), which means
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> On 2015/02/11 4:06, Stephen Frost wrote:
> >I had been trying to work out an FDW-specific way to address this, but I
> >think Dean's right that this should be addressed in
> >expand_security_qual(), which means it'll apply to all cases
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> On 2015/02/11 4:06, Stephen Frost wrote:
> >* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> >>On 2015/02/10 7:23, Dean Rasheed wrote:
> >>>Sorry, I didn't have time to look at this properly. My initial thought
> >>>is that expan
On 2015/02/11 4:06, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/10 7:23, Dean Rasheed wrote:
Sorry, I didn't have time to look at this properly. My initial thought
is that expand_security_qual() needs to request a lock on rows coming
>from the relation
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
> On 2015/02/10 7:23, Dean Rasheed wrote:
> >Sorry, I didn't have time to look at this properly. My initial thought
> >is that expand_security_qual() needs to request a lock on rows coming
> >from the relation it pushes down into a subqu
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 9 February 2015 at 21:17, Stephen Frost wrote:
> >> > On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
> >> > > I noticed that when updating security barrier views on foreign tables,
> >> > > we fail to give FOR UPDATE to selection queries
On 2015/02/10 7:23, Dean Rasheed wrote:
On 9 February 2015 at 21:17, Stephen Frost wrote:
On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
I noticed that when updating security barrier views on foreign tables,
we fail to give FOR UPDATE to selection queries issued at ForeignScan.
I've looked
On 9 February 2015 at 21:17, Stephen Frost wrote:
>> > On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
>> > > I noticed that when updating security barrier views on foreign tables,
>> > > we fail to give FOR UPDATE to selection queries issued at ForeignScan.
>>
> I've looked into this a fair bit mo
* Stephen Frost (sfr...@snowman.net) wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
> > wrote:
> > > I noticed that when updating security barrier views on foreign tables,
> > > we fail to give FOR UPDATE to selection queries issued at Fore
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
> wrote:
> > I noticed that when updating security barrier views on foreign tables,
> > we fail to give FOR UPDATE to selection queries issued at ForeignScan.
> > Here is an example.
[...]
> > postgres=#
On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
wrote:
> I noticed that when updating security barrier views on foreign tables,
> we fail to give FOR UPDATE to selection queries issued at ForeignScan.
> Here is an example.
>
> postgres=# create foreign table base_ftbl (person text, visibility text)
Hi,
I noticed that when updating security barrier views on foreign tables,
we fail to give FOR UPDATE to selection queries issued at ForeignScan.
Here is an example.
postgres=# create foreign table base_ftbl (person text, visibility text)
server loopback options (table_name 'base_tbl');
CREATE FO
23 matches
Mail list logo
