On Sun, Nov 18, 2018 at 06:32:42PM -0500, Tom Lane wrote:
> So at this point I'm not sure what to think, other than that things
> are inconsistent (and underdocumented).
Nagata-san, do you have some plans to do something about the comments
raised. The thread has been inactive for a couple of
"David G. Johnston" writes:
> On Sat, Aug 25, 2018 at 8:29 PM, Tom Lane wrote:
>> There's a backwards-compatibility argument for not changing this behavior,
>> sure, but I don't buy the other arguments you made here. And I don't
>> think there's all that much to the backwards-compatibility
On Sat, Aug 25, 2018 at 8:29 PM, Tom Lane wrote:
> There's a backwards-compatibility argument for not changing this behavior,
> sure, but I don't buy the other arguments you made here. And I don't
> think there's all that much to the backwards-compatibility argument,
> considering that the
Yugo Nagata writes:
> Tom Lane wrote:
>> There's a backwards-compatibility argument for not changing this behavior,
>> sure, but I don't buy the other arguments you made here. And I don't
>> think there's all that much to the backwards-compatibility argument,
>> considering that the current
On Sat, 25 Aug 2018 23:29:27 -0400
Tom Lane wrote:
> Robert Haas writes:
> > I'm not sure that it's a good idea to change this behavior.
>
> > In the case of an unqualified name, the permissions on the schemas in
> > the search path can affect which table is chosen in the first place.
> > ...
Robert Haas writes:
> I'm not sure that it's a good idea to change this behavior.
> In the case of an unqualified name, the permissions on the schemas in
> the search path can affect which table is chosen in the first place.
> ... So I think this only matters for qualified names.
Yeah, that
On Fri, Aug 24, 2018 at 5:31 AM, Yugo Nagata wrote:
> Although the behavior of the original function would reflect pg_class.relacl,
> it seems to
> me that the function fixed in my patch is more useful for users because this
> reflects
> the actual accessibility during query execution.
I'm not
Hi,
I updated the patch to support other has_*_privilege functions with some
refactoring, but tests for theses fixes are not included yet.
But, while running the regression test after this patch is applied, I found
that my patch doesn't pass privilege test. One of different behaviours
is as
On Thu, 16 Aug 2018 19:37:42 -0400
Tom Lane wrote:
> Yugo Nagata writes:
> > I found that has_table_privilege returns an error when a table is specified
> > by schema-qualified name and the user doen't have privilege for its schema.
>
> > postgres=> select
Yugo Nagata writes:
> I found that has_table_privilege returns an error when a table is specified
> by schema-qualified name and the user doen't have privilege for its schema.
> postgres=> select has_table_privilege('myschema.tbl','select');
> ERROR: permission denied for schema myschema
> I
Hi,
I found that has_table_privilege returns an error when a table is specified
by schema-qualified name and the user doen't have privilege for its schema.
postgres=> select has_table_privilege('myschema.tbl','select');
ERROR: permission denied for schema myschema
I think that this function
11 matches
Mail list logo
