On Mon, 21 Mar 2022 at 09:47, Laurenz Albe wrote:
>
> Thanks for your diligent work on this, and the patch looks good to me.
Thanks for looking again. Pushed.
Regards,
Dean
On Mon, 21 Mar 2022 at 20:40, Laurenz Albe wrote:
> On Mon, 2022-03-21 at 18:09 +0800, Japin Li wrote:
>> After apply the patch, I found pg_checksums.c also has the similar code.
>>
>> In progress_report(), I'm not sure we can do this replace for this code.
>>
>> snprintf(total_size_str,
On Mon, 2022-03-21 at 18:09 +0800, Japin Li wrote:
> After apply the patch, I found pg_checksums.c also has the similar code.
>
> In progress_report(), I'm not sure we can do this replace for this code.
>
> snprintf(total_size_str, sizeof(total_size_str), INT64_FORMAT,
>
On Sat, 2022-03-19 at 01:10 +, Dean Rasheed wrote:
> I have been hacking on it a bit, and attached is an updated version.
> Aside from some general copy editing, the most notable changes are:
> [...]
Thanks for your diligent work on this, and the patch looks good to me.
It is good that you
On Mon, 14 Mar 2022 at 16:16, Laurenz Albe wrote:
>
> The patch is fine from my point of view.
>
> It passes "make check-world".
>
> I'll mark it as "ready for committer".
>
Cool, thanks. I think this will make a useful addition to PG15.
I have been hacking on it a bit, and attached is an
On Mon, 2022-03-14 at 13:40 +0100, Christoph Heiss wrote:
> On 3/9/22 16:06, Laurenz Albe wrote:
> > This paragraph contains a couple of grammatical errors.
>
> Replaced the two paragraphs with your suggestion, it is indeed easier to
> read.
>
> > Also, this:
> > could be written like this
On 3/9/22 16:06, Laurenz Albe wrote:
This paragraph contains a couple of grammatical errors.
How about
Note that the user performing the insert, update or delete on the view
must have the corresponding insert, update or delete privilege on the
view. Unless security_invoker is
On Tue, 2022-03-08 at 18:17 +0100, Christoph Heiss wrote:
> Since there don't seem to be any more objections to "security_invoker" I
> attached v10 renaming it again.
>
> I've tried to better clarify the whole invoker vs. definer thing in the
> CREATE VIEW documentation by explicitly mentioning
On 3/2/22 11:10, Dean Rasheed wrote:
For my part, I find myself more and more convinced that
"security_invoker" is the right name, because it matches the
terminology used for functions, and in other database systems. I think
the parallels between security invoker functions and security invoker
On Wed, 2022-03-02 at 10:10 +, Dean Rasheed wrote:
> > I kept "check_permissions_owner" for now. Constantly changing it around
> > with each iteration doesn't really bring any value IMHO, I'd rather have
> > a final consensus on how to name the option and *then* change it for good.
>
> Yes
Dean Rasheed:
That is also the main reason I preferred naming it "security_invoker" -
it is consistent with other databases and eases transition from such
systems.
[...]
For my part, I find myself more and more convinced that
"security_invoker" is the right name, because it matches the
On Tue, 1 Mar 2022 at 16:40, Christoph Heiss
wrote:
>
> That is also the main reason I preferred naming it "security_invoker" -
> it is consistent with other databases and eases transition from such
> systems.
>
> I kept "check_permissions_owner" for now. Constantly changing it around
> with each
Thanks for reviewing!
On 2/25/22 19:22, Dean Rasheed wrote:
Re-reading this thread, I think I preferred the name
"security_invoker". The main objection seemed to come from the
potential confusion with SECURITY INVOKER/DEFINER functions, but I
think that's really a different thing. As long as
On Fri, 18 Feb 2022 at 14:57, Laurenz Albe wrote:
>
> Here is a new version, with improved documentation and the option renamed
> to "check_permissions_owner". I just prefer the shorter form.
>
Re-reading this thread, I think I preferred the name
"security_invoker". The main objection seemed to
On Tue, 2022-02-15 at 16:32 +0100, walt...@technowledgy.de wrote:
> > "check_permissions_as_owner" is ok with me, but a bit long.
>
> check_permissions_as_owner is exactly what happens. The additional "as"
> shouldn't be a problem in length - but is much better to read. I
> wouldn't associate
Laurenz Albe:
I'd be happy with "check_as_owner", except it is unclear *what* is checked.
Yeah, that could be associated with WITH CHECK OPTION, too, as in "do
the CHECK OPTION stuff as the owner".
"check_permissions_as_owner" is ok with me, but a bit long.
check_permissions_as_owner is
On Tue, 2022-02-15 at 16:07 +0100, walt...@technowledgy.de wrote:
> Laurenz Albe:
> > > I converted the option to run_as_owner=true|false in the attached v7.
> > > It now definitely seems like the right way to move forward and getting
> > > more feedback.
> > I think we are straying from the
Laurenz Albe:
I converted the option to run_as_owner=true|false in the attached v7.
It now definitely seems like the right way to move forward and getting
more feedback.
I think we are straying from the target.
"run_as_owner" seems wrong to me, because it is all about permission
checking
On Tue, 2022-02-15 at 13:02 +0100, Christoph Heiss wrote:
> > >
> I converted the option to run_as_owner=true|false in the attached v7.
> It now definitely seems like the right way to move forward and getting
> more feedback.
I think we are straying from the target.
"run_as_owner" seems wrong
Hi,
On 2/15/22 09:37, walt...@technowledgy.de wrote:
Christoph Heiss:
xxx_owner=true would be the default and xxx_owner=false could be set
explicitly to get the behavior we are looking for in this patch?
I'm not sure if an option which is on by default would be best, IMHO.
I would rather
Christoph Heiss:
xxx_owner=true would be the default and xxx_owner=false could be set
explicitly to get the behavior we are looking for in this patch?
I'm not sure if an option which is on by default would be best, IMHO. I
would rather have an off-by-default option, so that you explicitly
Laurenz Albe:
So even though the view owner "duff" has no permissions
on the schema "viewtest", we can still select from the table.
Permissions on the schema containing the table are not
checked, only permissions on the table itself.
I am not sure how to feel about this. It is not what I would
Hi all,
again, many thanks for the reviews and testing!
On 2/4/22 17:09, Laurenz Albe wrote:
I also see no reason to split a small patch like this into three parts.
I've split it into the three unrelated parts (code, docs, tests) to ease
review, but I happily carry it as one patch too.
In
Laurenz Albe:
So even though the view owner "duff" has no permissions
on the schema "viewtest", we can still select from the table.
Permissions on the schema containing the table are not
checked, only permissions on the table itself.
[...]
If not, I don't know if it is the business of this
On Fri, 2022-02-04 at 22:28 +0100, walt...@technowledgy.de wrote:
> This is a feature I have long been looking for. I tested the patch (v5)
> and found two cases that I feel need to be either fixed or documented
> explicitly.
Thanks for testing and weighing in!
> Case 1 - Schema privileges:
>
Christoph Heiss wrote:
As part of a customer project we are looking to implement an reloption for
views which when set, runs the subquery as invoked by the user rather than the
view owner, as is currently the case.
The rewrite rule's table references are then checked as if the user were
On Wed, 2022-02-02 at 18:23 +0100, Christoph Heiss wrote:
> > Huh? "duff" has no permission to insert into "tab"!
> That really should not happen, thanks for finding that and helping me
> investigating on how to fix that!
>
> This is now solved by checking the security_invoker property on the
Hi Laurenz,
thank you again for the review!
On 1/20/22 15:20, Laurenz Albe wrote:
[..]
I gave the new patch a spin, and got a surprising result:
[..]
INSERT INTO v VALUES (1);
INSERT 0 1
Huh? "duff" has no permission to insert into "tab"!
That really should not happen, thanks for
On Tue, 2022-01-18 at 16:16 +0100, Christoph Heiss wrote:
> > I think that this should be a boolean reloption, for example
> > "security_definer".
> > If unset or set to "off", you would get the current behavior.
>
> A boolean option would have been indeed the better choice, I agree.
> I haven't
Hi,
On 1/19/22 09:30, Julien Rouhaud wrote:
Hi,
On Tue, Jan 18, 2022 at 04:16:53PM +0100, Christoph Heiss wrote:
I've attached a v2 where I addressed the things you mentioned.
This version unfortunately doesn't apply anymore:
http://cfbot.cputube.org/patch_36_3466.log
=== Applying patches
Hi,
On Tue, Jan 18, 2022 at 04:16:53PM +0100, Christoph Heiss wrote:
>
> I've attached a v2 where I addressed the things you mentioned.
This version unfortunately doesn't apply anymore:
http://cfbot.cputube.org/patch_36_3466.log
=== Applying patches on top of PostgreSQL commit ID
Hi Laurenz,
thanks for the review!
I've attached a v2 where I addressed the things you mentioned.
On 1/11/22 19:59, Laurenz Albe wrote:
[..]
You made that an enum with only a single value.
What other values could you imagine in the future?
I think that this should be a boolean reloption, for
On Fri, 2021-12-17 at 18:31 +0100, Christoph Heiss wrote:
> As part of a customer project we are looking to implement an reloption
> for views which when set, runs the subquery as invoked by the user
> rather than the view owner, as is currently the case.
> The rewrite rule's table references
Hi all!
As part of a customer project we are looking to implement an reloption
for views which when set, runs the subquery as invoked by the user
rather than the view owner, as is currently the case.
The rewrite rule's table references are then checked as if the user were
referencing the
34 matches
Mail list logo
