>
>
> Bruce wrote:
> > This sounds great to me. As you have added to RangeTableEntry, I assume
> > you also added the needed fields to copyfuncs.c/outfuncs.c/makefuncs.c
> > and anywhere else that needs it. I will add this to the developers FAQ.
>
> Only to copyfuncs.c now. Is it possible that they get
> output/reread after deepRewriteQuery()?. I don't think so.
> And since makenode() initializes the allocated memory to
> nulls aclSkip defaults to false.
It doesn't matter whether we think it will never be used. If it says it
copies a structure, we have to make it work. Never know how it will be
used in the future. I went through all the copy/make/read/out files to
make sure every element of every structure was output, where possible.
I have added this to the developers FAQ, and it is on our web page.
>
> > > We add a bool to pg_class that let's the rewrite handler know
> > > if he really should set the aclSkip defaulting to false. On
> > > ownership changes this flag is reset to false and only the
> > > owner or superusers might set it.
> >
> > No, that is not what I was saying. If they can create views, the can
> > change pg_rewrite, and because we now take the view as the owners
> > permission granting, someone could change anything in pg_rewrite and
> > make it look like it is a view of someone else. They could change the
> > view text to look at pg_user, for example.
>
> Instead of granting users access to pg_rewrite we should use
> again some mechanism in rewriteDefine/ExecCheckPerms to let
> users only create rules through the CREATE RULE command. Not
> by INSERT INTO pg_rewrite. Then we can check during the
> creation of a rule that the user is the owner of the relation
> the rule is on. Totally safe then.
Yep. Need this for pg_database too.
--
Bruce Momjian
maillist@candle.pha.pa.us
