Re: Row-security on updatable s.b. views

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Yeb Havinga <y(dot)t(dot)havinga(at)mgrid(dot)net>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Smith <greg(dot)smith(at)crunchydatasolutions(dot)com>
Subject: Re: Row-security on updatable s.b. views
Date: 2014-03-07 17:56:38
Message-ID: 19037.1394214998@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> What I'm concerned about is the locking. It looks to me like we're
> causing the user to lock rows that they may not intend to lock, by
> applying a LockRows step *before* the user supplied qual. (I'm going to
> test that tomorrow, it's sleep time in Australia).

The fact that there are two LockRows nodes seems outright broken.
The one at the top of the plan is correctly placed, but how did the
other one get in there?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2014-03-07 18:04:40 Re: What the heck is hobby.2ndquadrant.com?
Previous Message Peter LaDow 2014-03-07 17:50:15 Re: atexit_callback can be a net negative