> On 5 Jul 2020, at 16:16, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> This patch still hasn't progressed since Tom's draft patch, is anyone still
>> interested in pursuing it or should we close it for now?
>
> It seems clearly reasonable to me to close the CF item as RWF,
> expecting
Daniel Gustafsson writes:
> This patch still hasn't progressed since Tom's draft patch, is anyone still
> interested in pursuing it or should we close it for now?
It seems clearly reasonable to me to close the CF item as RWF,
expecting that a new one can be made whenever somebody re-tackles
this
> On 25 Mar 2020, at 15:52, David Steele wrote:
> On 12/26/19 6:46 PM, Tom Lane wrote:
>> Awhile back I wrote:
>>> Actually ... maybe we don't need to change the view definition at all,
>>> but instead just make has_column_privilege() do something different
>>> for indexes than it does for other
Hi Pierre,
On 12/26/19 6:46 PM, Tom Lane wrote:
Awhile back I wrote:
Actually ... maybe we don't need to change the view definition at all,
but instead just make has_column_privilege() do something different
for indexes than it does for other relation types. It's dubious that
applying that
Awhile back I wrote:
> Actually ... maybe we don't need to change the view definition at all,
> but instead just make has_column_privilege() do something different
> for indexes than it does for other relation types. It's dubious that
> applying that function to an index yields anything
On Thu, Sep 05, 2019 at 04:56:40PM -0400, Tom Lane wrote:
> As coded, this certainly breaks pg_stat for those, and for foreign tables
> as well. Likely better to write something like
> "case when relkind = 'i' then do-something-for-indexes else old-code end".
Pierre, as an author of the patch
Alvaro Herrera writes:
> Hmm. This seems to create a large performance drop.
Yeah. It's also flat out wrong for indexes that depend on whole-row
variables. For that case, we really need to insist that the user
have select privilege on all the table columns, but this won't
accomplish that. It
On 2019-Sep-03, Pierre Ducroquet wrote:
> > IIUC, the patch introduces an additional privilege check for the
> > underlying objects involved in the expression/functional index. If the
> > user has 'select' privileges on all of the columns/objects included in
> > the expression/functional index,
BTW you labelled this in the CF app as targetting "stable", but I don't
think this is backpatchable. I think we should fix it in master and
call it a day. Changing system view definitions in stable versions is
tough.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL
On Wed, Sep 4, 2019 at 12:23 AM Pierre Ducroquet wrote:
>
> All my apologies for that. I submitted this patch some time ago but forgot to
> add it to the commit fest. Attached to this mail is a rebased version.
>
Thank you for the new version of the patch. It looks good to me.
Moving the status
On Tuesday, September 3, 2019 12:39:51 PM CEST Kuntal Ghosh wrote:
> Hello Pierre,
Hello Kuntal
>
> > When using a functional index on a table, we realized that the permission
> > check done in pg_stats was incorrect and thus preventing valid access to
> > the statistics from users.
> >
> > The
Hello Pierre,
> When using a functional index on a table, we realized that the permission
> check done in pg_stats was incorrect and thus preventing valid access to the
> statistics from users.
>
> The attached patch fixes this by introducing a second path in privilege check
> in pg_stats view.
Hi
When using a functional index on a table, we realized that the permission
check done in pg_stats was incorrect and thus preventing valid access to the
statistics from users.
How to reproduce:
create table tbl1 (a integer, b integer);
insert into tbl1 select x, x % 50 from
13 matches
Mail list logo
