Re: [HACKERS] Running pgindent

> 
> 
> 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