I want to run pgindent before the final release.  Who has outstanding
patches they are sitting on that would be affected by this?  Only places
where we have added non-conforming code would be affected.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Thu, 19 Feb 1998 09:59:52 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Running pgindent
Bruce Momjian wrote:

> I want to run pgindent before the final release.  Who has outstanding
> patches they are sitting on that would be affected by this?  Only places
> where we have added non-conforming code would be affected.

Ack! Can you make at least three changes to pgindent before doing this?

1) for functions which look like
  datetime *
  abstime_datetime(int4 x)
  {
  ...
do not put a tab (or extra spaces) between "datetime" and "*".

For the end of functions which look like
  ...
  } /* abstime_datetime() */

do not put any tabs (or just one) between the "{" and the comment.

Also, some comments get wrapped to the next line, making some ugly sources;
perhaps pgindent should not touch comment lines at all? Or at least keep
things on the same line, messing with the tabbing only??




Thu, 19 Feb 1998 15:32:39 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Running pgindent
> 
> Bruce Momjian wrote:
> 
> > I want to run pgindent before the final release.  Who has outstanding
> > patches they are sitting on that would be affected by this?  Only places
> > where we have added non-conforming code would be affected.
> 
> Ack! Can you make at least three changes to pgindent before doing this?
> 
> 1) for functions which look like
>   datetime *
>   abstime_datetime(int4 x)
>   {
>   ...
> do not put a tab (or extra spaces) between "datetime" and "*".
> 
> For the end of functions which look like
>   ...
>   } /* abstime_datetime() */
> 
> do not put any tabs (or just one) between the "{" and the comment.
> 
> Also, some comments get wrapped to the next line, making some ugly sources;
> perhaps pgindent should not touch comment lines at all? Or at least keep
> things on the same line, messing with the tabbing only??

Well, that is what indent does.  I can try and work around it, but I am
afraid I will mess it up somehow.  Right now, all the stuff is indented
consistently, and running it again will only make the changed stuff look
like the rest.

Making a change will change all the code, even the unchanged stuff. 
Also, for comments, it will not change comments that are block-style. 
See the indent manual page and the flags I use for help.  Keep in mind I
use BSD indent, which does not have the bugs in GNU indent.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Thu, 19 Feb 1998 10:59:08 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Running pgindent
Bruce Momjian wrote:
> 
> I want to run pgindent before the final release.  Who has outstanding
> patches they are sitting on that would be affected by this?  Only places
> where we have added non-conforming code would be affected.

I'm changing bufmgr.c & elog.c to fix problems with smgrblind.

Vadim

Fri, 20 Feb 1998 09:03:12 +0700
"Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
Re: [HACKERS] Running pgindent
> 
> Bruce Momjian wrote:
> > 
> > I want to run pgindent before the final release.  Who has outstanding
> > patches they are sitting on that would be affected by this?  Only places
> > where we have added non-conforming code would be affected.
> 
> I'm changing bufmgr.c & elog.c to fix problems with smgrblind.
> 
> Vadim
> 

Let me know when you would like it done.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Thu, 19 Feb 1998 22:02:44 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Running pgindent
Bruce Momjian wrote:

> >
> > Bruce Momjian wrote:
> >
> > > I want to run pgindent before the final release.  Who has outstanding
> > > patches they are sitting on that would be affected by this?  Only places
> > > where we have added non-conforming code would be affected.
> >
> > Ack! Can you make at least three changes to pgindent before doing this?
> >
> > 1) for functions which look like
> >   datetime *
> >   abstime_datetime(int4 x)
> >   {
> >   ...
> > do not put a tab (or extra spaces) between "datetime" and "*".
> >
> > For the end of functions which look like
> >   ...
> >   } /* abstime_datetime() */
> >
> > do not put any tabs (or just one) between the "{" and the comment.
> >
> > Also, some comments get wrapped to the next line, making some ugly sources;
> > perhaps pgindent should not touch comment lines at all? Or at least keep
> > things on the same line, messing with the tabbing only??
>
> Well, that is what indent does.  I can try and work around it, but I am
> afraid I will mess it up somehow.  Right now, all the stuff is indented
> consistently, and running it again will only make the changed stuff look
> like the rest.
>
> Making a change will change all the code, even the unchanged stuff.
> Also, for comments, it will not change comments that are block-style.
> See the indent manual page and the flags I use for help.  Keep in mind I
> use BSD indent, which does not have the bugs in GNU indent.

Well, *&^*^#$! I wasted hours cleaning up some of what I considered damage from
the last pass through.
Would it be possible to pass back through (i.e. pipe indent output to a filter)
and fix at least points (1) and (2)? _That_ would be pretty easy to automate
since the heuristics can be pretty simple:

if (first char is nonwhitespace) && (next word is "*") && (next line starts with
word+paren)
then compress whitespace

else if (first char is "}") && (next word is "/*")
then compress whitespace

else
write line as-is

I'll write the perl if you would be willing to use it?

                                               - Tom


Fri, 20 Feb 1998 03:34:24 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Running pgindent
> 
> > 
> > Bruce Momjian wrote:
> > > 
> > > I want to run pgindent before the final release.  Who has outstanding
> > > patches they are sitting on that would be affected by this?  Only places
> > > where we have added non-conforming code would be affected.
> > 
> > I'm changing bufmgr.c & elog.c to fix problems with smgrblind.
> > 
> > Vadim
> > 
> 
> Let me know when you would like it done.

    Got very close to the view permission override - just a vew hours
    for me :-)

> 
> -- 
> Bruce Momjian
> maillist@candle.pha.pa.us
> 
> 


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #


Fri, 20 Feb 1998 11:52:06 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Running pgindent
> 
> > 
> > > 
> > > Bruce Momjian wrote:
> > > > 
> > > > I want to run pgindent before the final release.  Who has outstanding
> > > > patches they are sitting on that would be affected by this?  Only places
> > > > where we have added non-conforming code would be affected.
> > > 
> > > I'm changing bufmgr.c & elog.c to fix problems with smgrblind.
> > > 
> > > Vadim
> > > 
> > 
> > Let me know when you would like it done.
> 
>     Got very close to the view permission override - just a vew hours
>     for me :-)

Great.  I was thinking about this, and I think it would be best if the
view permissions were checked as the view owner at view USE time, not
view CREATION time, that way if permissions on the base tables change,
the permissions are properly honored.

I think the range table idea is good, so there is an OWNER field on each
range table which defaults to the current user.  As views are replaced
by base tables in the rewrite system, the owner can be changed to the
owner of the view.  The issue is whether the range table entry will be
available in the executor for you to access that owner field.  But at
this point, any fix for this would be great.  People are asking for this
view permissions thing.

Also, this makes non-super-user created views even harder, because if
people can create their own views, they can change the owner field to
anyone they want to, but that is for later.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Fri, 20 Feb 1998 10:29:43 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Running pgindent

Bruce wrote:
> >
> >     Got very close to the view permission override - just a vew hours
> >     for me :-)
>
> Great.  I was thinking about this, and I think it would be best if the
> view permissions were checked as the view owner at view USE time, not
> view CREATION time, that way if permissions on the base tables change,
> the permissions are properly honored.

    Did it that way as it looked better for me too. :-)

>
> I think the range table idea is good, so there is an OWNER field on each
> range table which defaults to the current user.  As views are replaced
> by base tables in the rewrite system, the owner can be changed to the
> owner of the view.  The issue is whether the range table entry will be
> available in the executor for you to access that owner field.  But at
> this point, any fix for this would be great.  People are asking for this
> view permissions thing.

    Done   much   easier.   Appended  a  bool  field  aclSkip  to
    RangeTblEntry that defaults to false due to makenode().  When
    the  rewriting  system finds a rule on select on the relation
    level, with exactly one action, the actions command type is a
    select  which  is  instead  (wow) it is a view. This time the
    rewrite handler checks acl for the range table entries in the
    rules  action  against  the owner of the table the rule is on
    (the view itself). On success it sets aclSkip to true.

    Later the  executor  in  ExecCheckPerms()  just  skips  these
    entries.   Since one range table entry for the view itself is
    left without the aclSkip  set  the  executor  checks  if  the
    current  user  has  access  rights for the view. But it skips
    those entries appended to the  range  table  by  the  rewrite
    handler accessing the real tables in question.

    One little thing isn't covered then. User A creates a view on
    a table he revoked from world and grants access to  the  view
    only to user B.  Now user B can create another view selecting
    A's view and grant that to world and this would  do  it.  But
    since  any  user  that  can read a view could simply copy the
    data into another table and grant that to world I don't see a
    really security problem here. Granting access to user implies
    IMHO you can trust that user.

>
> Also, this makes non-super-user created views even harder, because if
> people can create their own views, they can change the owner field to
> anyone they want to, but that is for later.

    Do they - hmmm that's not good. But  there  could  be  a  way
    round.  Really for later but let's keep the solution in mind.

    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.


Until later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Fri, 20 Feb 1998 18:22:33 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Running pgindent
> 
> 
> Bruce wrote:
> > >
> > >     Got very close to the view permission override - just a vew hours
> > >     for me :-)
> >
> > Great.  I was thinking about this, and I think it would be best if the
> > view permissions were checked as the view owner at view USE time, not
> > view CREATION time, that way if permissions on the base tables change,
> > the permissions are properly honored.
> 
>     Did it that way as it looked better for me too. :-)

Good.

> 
> >
> > I think the range table idea is good, so there is an OWNER field on each
> > range table which defaults to the current user.  As views are replaced
> > by base tables in the rewrite system, the owner can be changed to the
> > owner of the view.  The issue is whether the range table entry will be
> > available in the executor for you to access that owner field.  But at
> > this point, any fix for this would be great.  People are asking for this
> > view permissions thing.
> 
>     Done   much   easier.   Appended  a  bool  field  aclSkip  to
>     RangeTblEntry that defaults to false due to makenode().  When
>     the  rewriting  system finds a rule on select on the relation
>     level, with exactly one action, the actions command type is a
>     select  which  is  instead  (wow) it is a view. This time the
>     rewrite handler checks acl for the range table entries in the
>     rules  action  against  the owner of the table the rule is on
>     (the view itself). On success it sets aclSkip to true.
> 
>     Later the  executor  in  ExecCheckPerms()  just  skips  these
>     entries.   Since one range table entry for the view itself is
>     left without the aclSkip  set  the  executor  checks  if  the
>     current  user  has  access  rights for the view. But it skips
>     those entries appended to the  range  table  by  the  rewrite
>     handler accessing the real tables in question.
> 
>     One little thing isn't covered then. User A creates a view on
>     a table he revoked from world and grants access to  the  view
>     only to user B.  Now user B can create another view selecting
>     A's view and grant that to world and this would  do  it.  But
>     since  any  user  that  can read a view could simply copy the
>     data into another table and grant that to world I don't see a
>     really security problem here. Granting access to user implies
>     IMHO you can trust that user.

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.

> 
> >
> > Also, this makes non-super-user created views even harder, because if
> > people can create their own views, they can change the owner field to
> > anyone they want to, but that is for later.
> 
>     Do they - hmmm that's not good. But  there  could  be  a  way
>     round.  Really for later but let's keep the solution in mind.
> 
>     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.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Fri, 20 Feb 1998 14:12:46 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
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.

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


Until later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Fri, 20 Feb 1998 21:18:30 +0100 (MET)
jwieck@debis.com (Jan Wieck)
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

Fri, 20 Feb 1998 15:51:36 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Running pgindent
> >     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.

    Correct. I'll do it along with the flag in pg_class.


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #


Fri, 20 Feb 1998 21:58:15 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] Running pgindent
> 
> > >     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.
> 
>     Correct. I'll do it along with the flag in pg_class.

Can you remind me of the pg_class flag's purpose?

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Fri, 20 Feb 1998 16:21:19 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Running pgindent
If I ever get to run pgindent. I will make these changes, Tom.

> Well, *&^*^#$! I wasted hours cleaning up some of what I considered damage from
> the last pass through.
> Would it be possible to pass back through (i.e. pipe indent output to a filter)
> and fix at least points (1) and (2)? _That_ would be pretty easy to automate
> since the heuristics can be pretty simple:
> 
> if (first char is nonwhitespace) && (next word is "*") && (next line starts with
> word+paren)
> then compress whitespace
> 
> else if (first char is "}") && (next word is "/*")
> then compress whitespace
> 
> else
> write line as-is
> 
> I'll write the perl if you would be willing to use it?
> 
>                                                - Tom
> 
> 


-- 
Bruce Momjian
maillist@candle.pha.pa.us

Sat, 21 Feb 1998 21:04:49 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Running pgindent
> If I ever get to run pgindent. I will make these changes, Tom.

Ahhhhh. Thx. :)

                                       - Tom


Mon, 23 Feb 1998 14:37:44 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] Running pgindent
> Well, *&^*^#$! I wasted hours cleaning up some of what I considered damage from
> the last pass through.
> Would it be possible to pass back through (i.e. pipe indent output to a filter)
> and fix at least points (1) and (2)? _That_ would be pretty easy to automate
> since the heuristics can be pretty simple:
> 
> if (first char is nonwhitespace) && (next word is "*") && (next line starts with
> word+paren)
> then compress whitespace
> 
> else if (first char is "}") && (next word is "/*")
> then compress whitespace
> 
> else
> write line as-is
> 
> I'll write the perl if you would be willing to use it?

OK, I have changed pgindent to reflect the new structure names, and have
made your requested changes.  For #1, if the line began with an alpha,
and ends with a *, I remove tabs/spaces before the * and make it only
one space.  Let me know how you like the changes.

I have not run it on the source yet because people are still holding
patches.


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Tue, 24 Feb 1998 19:25:28 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Running pgindent
On Tue, 24 Feb 1998, Bruce Momjian wrote:

> OK, I have changed pgindent to reflect the new structure names, and have
> made your requested changes.  For #1, if the line began with an alpha,
> and ends with a *, I remove tabs/spaces before the * and make it only
> one space.  Let me know how you like the changes.
> 
> I have not run it on the source yet because people are still holding
> patches.

Bruce, do you run pgindent on the java sources aswell?

If you do, a couple of points:

	/* */ are as in C
	/**   same as /* but also marks the start of a comment (can be 
	      html) that javadoc will place in documentation.
	//    Single line comment

You may want to check that it doesn't mangle the last two.

-- 
Peter T Mount  petermount@earthling.net or pmount@maidast.demon.co.uk
Main Homepage: http://www.demon.co.uk/finder
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk


Wed, 25 Feb 1998 06:49:43 +0000 (GMT)
Peter T Mount <psqlhack@maidast.demon.co.uk>
Re: [HACKERS] Running pgindent
> 
> On Tue, 24 Feb 1998, Bruce Momjian wrote:
> 
> > OK, I have changed pgindent to reflect the new structure names, and have
> > made your requested changes.  For #1, if the line began with an alpha,
> > and ends with a *, I remove tabs/spaces before the * and make it only
> > one space.  Let me know how you like the changes.
> > 
> > I have not run it on the source yet because people are still holding
> > patches.
> 
> Bruce, do you run pgindent on the java sources aswell?
> 
> If you do, a couple of points:
> 
> 	/* */ are as in C
> 	/**   same as /* but also marks the start of a comment (can be 
> 	      html) that javadoc will place in documentation.
> 	//    Single line comment
> 
> You may want to check that it doesn't mangle the last two.

No, no run of C++ or Java.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Wed, 25 Feb 1998 09:17:19 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Running pgindent\