pgindent run coming

Started by Bruce Momjianover 16 years ago53 messages
#1Bruce Momjian
bruce@momjian.us

It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
running it at zero-hour GMT tomorrow, meaning five hours from now.
Any objections?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#2Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#1)
Re: pgindent run coming

Bruce Momjian wrote:

It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
running it at zero-hour GMT tomorrow, meaning five hours from now.
Any objections?

I ran pgindent and was concerned enough about the results so I am
posting here rather than applying any changes. I used the old way of
generating typedefs and the new buildfarm method output from diffs from
http://www.pgbuildfarm.org/cgi-bin/typedefs.pl. The typedef lists and
diff are here:

http://momjian.us/expire/pgindent/

You can see the typedef lists are of similar size:

2775 typedefs.old
2123 typedefs.new

and the diffs generates are a similar number of lines:

133657 diff.old_typedefs
135042 diff.new_typedefs

I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:

-   ret = stat(indir, &st);
+   ret = stat  (indir, &st);

and even odder:

-                       stat->weight |= 1 << 3;
+                       stat      ->weight |= 1 << 3;

stat was not a typedef in 8.3 or pgindent would have done this for 8.3,
but I can't figure out what has changed to make it appear for 8.4. I
see this in the objdump output (my OS has not changed from 8.3):

31357 EXCL 0 0 00003e64 97648 /usr/include/time.h
31358 EXCL 0 0 00007638 97624 /usr/include/sys/time.h
31359 EXCL 0 0 00000000 97648 /usr/include/time.h
31360 EXCL 0 0 00001dff 25540 /usr/include/fcntl.h
31361 BINCL 0 0 000144be 449667 /usr/include/sys/stat.h

31362 LSYM 0 0 00000000 449691 ostat:T(51,1)=s64st_dev:(0,9),0,16;st_ino:(9,20),32,32;st_mode:(9,22),64,16;st_nlink:(9,23),80,16;st_u
id:(0,9),96,16;st_gid:(0,9),112,16;st_rdev:(0,9),128,16;st_size:(0,3),160,32;st_atimespec:(48,2),192,64;st_mtimespec:(48,2),256,64;st_ctimespec:(4
8,2),320,64;st_blksize:(0,3),384,32;st_blocks:(0,3),416,32;st_flags:(0,5),448,32;st_gen:(0,5),480,32;;

31363 LSYM 0 0 00000000 450042 stat32:T(51,2)=s96st_dev:(9,17),0,32;st_ino:(9,20),32,32;st_mode:(9,22),64,16;st_nlink:(9,23),80,16;st
_uid:(9,28),96,32;st_gid:(9,19),128,32;st_rdev:(9,17),160,32;st_atimespec:(48,2),192,64;st_mtimespec:(48,2),256,64;st_ctimespec:(48,2),320,64;st_s
ize:(0,3),384,32;st_size1:(0,3),416,32;st_blocks:(0,3),448,32;st_blocks1:(0,3),480,32;st_blksize:(0,5),512,32;st_flags:(0,5),544,32;st_gen:(0,5),5
76,32;st_lspare:(0,3),608,32;st_qspare:(51,3)=ar(0,1);0;3;(0,3),640,128;;

--> 31364 LSYM 0 0 00000000 450510 stat:T(51,4)=s96st_dev:(9,17),0,32;st_ino:(9,20),32,32;st_mode:(9,22),64,16;st_nlink:(9,23),80,16;st_u
id:(9,28),96,32;st_gid:(9,19),128,32;st_rdev:(9,17),160,32;st_atimespec:(48,2),192,64;st_mtimespec:(48,2),256,64;st_ctimespec:(48,2),320,64;st_siz
e:(9,24),384,64;st_blocks:(9,8),448,64;st_blksize:(0,5),512,32;st_flags:(0,5),544,32;st_gen:(0,5),576,32;st_lspare:(0,3),608,32;st_qspare:(51,5)=a
r(0,1);0;1;(9,8),640,128;;

It is coming from the postgres binary.

The typedef is coming from the indicated line, and from
/usr/include/sys/stat.h, where there is no typedef for stat. Obviously
Linux or the buildfarm is finding the same issue, but I have no idea
why.

My only guess right now is that we are linking postgres differently than
we did for 8.3 and that is bringing in new wrong typedef symbols.

I will have to research this further tomorrow.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#3Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#2)
Re: pgindent run coming

Bruce Momjian wrote:

The typedef is coming from the indicated line, and from
/usr/include/sys/stat.h, where there is no typedef for stat. Obviously
Linux or the buildfarm is finding the same issue, but I have no idea
why.

My only guess right now is that we are linking postgres differently than
we did for 8.3 and that is bringing in new wrong typedef symbols.

I will have to research this further tomorrow.

I was able to reproduce the incorrect stat typedef here in a small test
program by just including "sys/stat.h" so I will research tomorrow how
to fix this.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#2)
Re: pgindent run coming

Bruce Momjian <bruce@momjian.us> writes:

I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:

The standard headers do define "struct stat". I wonder whether the
objdump kluge we are using is unable to distinguish typedef names
from struct tags.

I will have to research this further tomorrow.

We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?

regards, tom lane

#5Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#4)
Re: pgindent run coming

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:

The standard headers do define "struct stat". I wonder whether the
objdump kluge we are using is unable to distinguish typedef names
from struct tags.

I will have to research this further tomorrow.

We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?

The problem is that there are other symbols I don't know about and the
diff is very large. I have found that the problem was caused when we
added Linux support to find_typedef and I have a way to get an accurate
list on my machine.

I will generate a proper list on my machine tomorrow then test Linux
here to see if I can get it to generate the right list too. But odds
are we are not going to have time to re-run the list on the build farm
even if I can get Linux working here.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#6Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#4)
Re: pgindent run coming

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:

The standard headers do define "struct stat". I wonder whether the
objdump kluge we are using is unable to distinguish typedef names
from struct tags.

I will have to research this further tomorrow.

We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?

Do you want me to just run with my old typedef list now and apply it?
We an always rerun tomorrow if we get a better typedef list.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#6)
Re: pgindent run coming

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?

Do you want me to just run with my old typedef list now and apply it?
We an always rerun tomorrow if we get a better typedef list.

I'd rather have *one* run with the final typedef list. If you don't
have that list yet, wait till you do.

regards, tom lane

#8Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#7)
Re: pgindent run coming

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?

Do you want me to just run with my old typedef list now and apply it?
We an always rerun tomorrow if we get a better typedef list.

I'd rather have *one* run with the final typedef list. If you don't
have that list yet, wait till you do.

OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS HEAD?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#9Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#8)
Re: pgindent run coming

Bruce Momjian wrote:

OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS HEAD?

The buildfarm does not run the find-typedefs script. Its code for this
is below. My Unix machine runs this once a day. I can do runs on Windows
and Cygwin manually.

If there is changed logic tell me what it is and I'll try to get it done.

cheers

andrew

-----------------
sub find_typedefs
{
my @err = `objdump -W 2>&1`;
@err = () if `uname -s 2>&1` =~ /CYGWIN/i;
my %syms;
my @dumpout;
my @flds;
foreach my $bin (glob("$installdir/bin/*"),
glob("$installdir/lib/*"),
glob("$installdir/lib/postgresql/*"))
{
next if $bin =~ m!bin/(ipcclean|pltcl_)!;
next unless -f $bin;
if (@err == 1) # Linux
{
@dumpout = `objdump -W $bin 2>/dev/null | egrep -A3
'(DW_TAG_typedef|DW_TAG_structure_type|DW_TAG_union_type)' 2>/dev/null`;
foreach (@dumpout)
{
@flds = split;
next if (($flds[0] ne 'DW_AT_name' && $flds[1] ne 'DW_AT_name' ) ||
$flds[-1] =~ /^DW_FORM_str/);
$syms{$flds[-1]} =1;
}
}
else
{
@dumpout = `objdump --stabs $bin 2>/dev/null`;
foreach (@dumpout)
{
@flds = split;
next if (@flds < 7);
next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):[tT]/);
$syms{$1} =1;
}
}
}
my @badsyms = grep { /\s/ } keys %syms;
push(@badsyms,'date','interval','timestamp','ANY');
delete @syms{@badsyms};

my @goodsyms = sort keys %syms;
my @foundsyms;

my %foundwords;

my $setfound = sub
{
return unless (-f $_ && /^.*\.[chly]\z/);
my @lines;
my $handle;
open ($handle,$_);
while (my $line=<$handle>)
{
foreach my $word (split(/\W+/,$line))
{
$foundwords{$word} = 1;
}
}
close($handle);
};

File::Find::find($setfound,"$branch_root/pgsql");

foreach my $sym (@goodsyms)
{
push(@foundsyms,"$sym\n") if exists $foundwords{$sym};
}

writelog('typedefs',\@foundsyms);
$steps_completed .= " find-typedefs";
}

#10Simon Riggs
simon@2ndQuadrant.com
In reply to: Bruce Momjian (#1)
Re: pgindent run coming

On Tue, 2009-06-09 at 13:21 -0400, Bruce Momjian wrote:

It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
running it at zero-hour GMT tomorrow, meaning five hours from now.
Any objections?

Why don't we do this automatically after each individual commit? That
way each commit would be associated directly with any required tidy-up
that must occur because of it.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

#11Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#9)
1 attachment(s)
Re: pgindent run coming

Andrew Dunstan wrote:

Bruce Momjian wrote:

OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS HEAD?

The buildfarm does not run the find-typedefs script. Its code for this
is below. My Unix machine runs this once a day. I can do runs on Windows
and Cygwin manually.

If there is changed logic tell me what it is and I'll try to get it done.

Yes, please make the attached change, and rerun the script. This change
reflects the changes I made in src/tools/find_typedef.

What value is there if the URL I have just runs on Linux? It probably
has the same coverage I have for BSD. I asked for something that was
automated for more platforms a year ago and I still don't have it? I
might as well just use the same method I have have used for years.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachments:

/rtmp/difftext/x-diffDownload
*** ./script.pl.orig	Wed Jun 10 09:39:27 2009
--- ./script.pl	Wed Jun 10 09:39:39 2009
***************
*** 30,36 ****
  {
  @flds = split;
  next if (@flds < 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):[tT]/);
  $syms{$1} =1;
  }
  }
--- 30,36 ----
  {
  @flds = split;
  next if (@flds < 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):t/);
  $syms{$1} =1;
  }
  }
#12Tom Lane
tgl@sss.pgh.pa.us
In reply to: Simon Riggs (#10)
Re: pgindent run coming

Simon Riggs <simon@2ndQuadrant.com> writes:

On Tue, 2009-06-09 at 13:21 -0400, Bruce Momjian wrote:

It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
running it at zero-hour GMT tomorrow, meaning five hours from now.

Why don't we do this automatically after each individual commit?

It's not very practical until the typedef extraction stuff is fully
automatic and fully trustworthy; right now some manual review and
intervention still seems like a good idea.

Also, that would risk breaking series of interdependent patches.

regards, tom lane

#13Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#4)
Re: pgindent run coming

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:

The standard headers do define "struct stat". I wonder whether the
objdump kluge we are using is unable to distinguish typedef names
from struct tags.

I will have to research this further tomorrow.

We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?

I agree we are running out of time so I will be running pgindent in one
hour using the same BSD-based typedef method I have used in the past.
If a better typedef list appears, we can always rerun pgindent.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#14Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#13)
Re: pgindent run coming

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?

I agree we are running out of time so I will be running pgindent in one
hour using the same BSD-based typedef method I have used in the past.
If a better typedef list appears, we can always rerun pgindent.

Why not compare the BSD list with the new one and adopt anything that
seems sane? We know that your old method misses quite a lot of typedefs.

regards, tom lane

#15Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#11)
Re: pgindent run coming

Bruce Momjian wrote:

Andrew Dunstan wrote:

Bruce Momjian wrote:

OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS HEAD?

The buildfarm does not run the find-typedefs script. Its code for this
is below. My Unix machine runs this once a day. I can do runs on Windows
and Cygwin manually.

If there is changed logic tell me what it is and I'll try to get it done.

Yes, please make the attached change, and rerun the script. This change
reflects the changes I made in src/tools/find_typedef.

What value is there if the URL I have just runs on Linux? It probably
has the same coverage I have for BSD. I asked for something that was
automated for more platforms a year ago and I still don't have it? I
might as well just use the same method I have have used for years.

Well, sometimes I build it and they don't come ;-).

I don't have every platform under the sun that I can run this on,
although I do now have an FBSD VM that I didn't have when I worked on
this previously. If you're actually going to use it I'll set it up as a
buildfarm member and run the find-typedefs there.

I will make the change you request and rerun the stuff on the platforms
I have that are currently buildfarm members, but AFAICT the Linux output
will still include the stat symbol (your change doesn't affect the Linux
branch at all).

Both my version and yours contains provision for filtering out certain
symbols ('timestamp' etc). Maybe we need to add 'stat' to that list.

cheers

andrew

Show quoted text

------------------------------------------------------------------------

*** ./script.pl.orig	Wed Jun 10 09:39:27 2009
--- ./script.pl	Wed Jun 10 09:39:39 2009
***************
*** 30,36 ****
{
@flds = split;
next if (@flds < 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):[tT]/);
$syms{$1} =1;
}
}
--- 30,36 ----
{
@flds = split;
next if (@flds < 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):t/);
$syms{$1} =1;
}
}
#16Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#15)
1 attachment(s)
Re: pgindent run coming

Andrew Dunstan wrote:

Well, sometimes I build it and they don't come ;-).

I don't have every platform under the sun that I can run this on,
although I do now have an FBSD VM that I didn't have when I worked on
this previously. If you're actually going to use it I'll set it up as a
buildfarm member and run the find-typedefs there.

I will make the change you request and rerun the stuff on the platforms
I have that are currently buildfarm members, but AFAICT the Linux output
will still include the stat symbol (your change doesn't affect the Linux
branch at all).

Good point. Here is another diff I need you to make to the pl file.
If you want to make your pl file the official version and replace the
shell script in CVS, that is fine with me. Do you want me to do that?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachments:

/rtmp/difftext/x-diffDownload
*** ./script.pl.orig	Wed Jun 10 09:39:27 2009
--- ./script.pl	Wed Jun 10 11:09:36 2009
***************
*** 14,20 ****
  if (@err == 1) # Linux
  {
  @dumpout = `objdump -W $bin 2>/dev/null | egrep -A3 
! '(DW_TAG_typedef|DW_TAG_structure_type|DW_TAG_union_type)' 2>/dev/null`;
  foreach (@dumpout)
  {
  @flds = split;
--- 14,20 ----
  if (@err == 1) # Linux
  {
  @dumpout = `objdump -W $bin 2>/dev/null | egrep -A3 
! 'DW_TAG_typedef' 2>/dev/null`;
  foreach (@dumpout)
  {
  @flds = split;
#17Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#16)
Re: pgindent run coming

Bruce Momjian wrote:

Good point. Here is another diff I need you to make to the pl file.

Done. Linux run under way.

If you want to make your pl file the official version and replace the
shell script in CVS, that is fine with me. Do you want me to do that?

It needs to be done in two pieces, I think: a perl module that exports a
function that can be called from the buildfarm, and program that calls
it so it can be run standalone. The function needs two inputs: an
installation directory and a source directory. Then we will be able to
stay in sync nicely. I will try to do that over the next day or so if
you like.

Or we can just wing it for now and do this after the release.

cheers

andrew

#18Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#5)
Re: pgindent run coming

Bruce Momjian wrote:

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:

The standard headers do define "struct stat". I wonder whether the
objdump kluge we are using is unable to distinguish typedef names
from struct tags.

I will have to research this further tomorrow.

We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?

The problem is that there are other symbols I don't know about and the
diff is very large. I have found that the problem was caused when we
added Linux support to find_typedef and I have a way to get an accurate
list on my machine.

OK, I have found the cause of the script error, and it was my fault. A
month after we ran pgindent for 8.3 (December 2007), I received this
issue from Tom:

http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php

Something I noticed the other day is that pgindent doesn't seem to treat
"struct foo" or "union foo" as a type name, which is pretty silly
because no context is needed at all to recognize that. We tend not to
do that too much --- the project style is to use a typedef name --- but
there are some places that do it, particularly the regex code. For
instance there are extra spaces here:

static void
cmtreefree(struct colormap * cm,
union tree * tree,
int level) /* level number (top == 0) of this
block */
{

Fixable?

Not understanding the ramifications of adding struct and union tags to
the typedef list, I modified the BSD code:

http://archives.postgresql.org/pgsql-hackers/2007-12/msg00810.php

Yes, I found those are 't' STABS rather than "T" which are used in cases
where you do typedef struct {} name. The next pgindent will have those
typedefs you want.

and that modification was propogated to the Linux code.

This has now been fixed in the BSD and Linux code (and Perl script) and
we can move forward with running pgindent once Andrew has lists for all
the platforms he wants.

As for Tom's original complaint about, it seems BSD indent is just not
smart enough about struct/union tags. I will look into fixing that
after 8.4 pgindent is run.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#19Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#17)
Re: pgindent run coming

Andrew Dunstan wrote:

Bruce Momjian wrote:

Good point. Here is another diff I need you to make to the pl file.

Done. Linux run under way.

If you want to make your pl file the official version and replace the
shell script in CVS, that is fine with me. Do you want me to do that?

It needs to be done in two pieces, I think: a perl module that exports a
function that can be called from the buildfarm, and program that calls
it so it can be run standalone. The function needs two inputs: an
installation directory and a source directory. Then we will be able to
stay in sync nicely. I will try to do that over the next day or so if
you like.

Or we can just wing it for now and do this after the release.

We have to wing it for now. Please let me know when whatever lists you
can generate are ready, hopefully in the next few hours.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#20Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#18)
Re: pgindent run coming

Bruce Momjian <bruce@momjian.us> writes:

OK, I have found the cause of the script error, and it was my fault. A
month after we ran pgindent for 8.3 (December 2007), I received this
issue from Tom:

http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php

Something I noticed the other day is that pgindent doesn't seem to treat
"struct foo" or "union foo" as a type name, which is pretty silly
because no context is needed at all to recognize that.

Ah. So really the point here is that we want to specifically exclude
"struct stat" because there are too many places in our code where "stat"
is used as a regular identifier. Are there any other special cases like
that?

regards, tom lane

#21Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#20)
Re: pgindent run coming

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

OK, I have found the cause of the script error, and it was my fault. A
month after we ran pgindent for 8.3 (December 2007), I received this
issue from Tom:

http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php

Something I noticed the other day is that pgindent doesn't seem to treat
"struct foo" or "union foo" as a type name, which is pretty silly
because no context is needed at all to recognize that.

Ah. So really the point here is that we want to specifically exclude
"struct stat" because there are too many places in our code where "stat"
is used as a regular identifier. Are there any other special cases like
that?

Yep, lots. I see "option" also doing strange things, and some others.
You can see the diff here:

http://momjian.us/expire/pgindent/http://momjian.us/expire/pgindent/

Basically that list is meant for typedefs, not struct or union tags.
The BSD indent manual page says:

-Ttypename Adds typename to the list of type keywords. Names accu-
mulate: -T can be specified more than once. You need to
specify all the typenames that appear in your program
that are defined by typedef - nothing will be harmed if
you miss a few, but the program won't be formatted as
nicely as it should. This sounds like a painful thing to
have to do, but it's really a symptom of a problem in C:
typedef causes a syntactic change in the language and
indent can't find all instances of typedef.

I am unclear why struct pointers are not being formatted properly in
function headers but will research it.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#22Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#21)
Re: pgindent run coming

Bruce Momjian <bruce@momjian.us> writes:

I am unclear why struct pointers are not being formatted properly in
function headers but will research it.

Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do right now.

Have you started the pgindent run yet? I have a patch ready for
the cursor stability issue, but will hold off committing if it might
create a merge problem for you.

regards, tom lane

#23Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#22)
Re: pgindent run coming

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I am unclear why struct pointers are not being formatted properly in
function headers but will research it.

Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do right now.

Have you started the pgindent run yet? I have a patch ready for
the cursor stability issue, but will hold off committing if it might
create a merge problem for you.

I am waiting for Andrew to tell me he is ready with updated lists for
his platforms. His CGI output is now _not_ showing stat so I am
comparing the lists now.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#24Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#23)
Re: pgindent run coming

Bruce Momjian <bruce@momjian.us> writes:

Have you started the pgindent run yet? I have a patch ready for
the cursor stability issue, but will hold off committing if it might
create a merge problem for you.

I am waiting for Andrew to tell me he is ready with updated lists for
his platforms. His CGI output is now _not_ showing stat so I am
comparing the lists now.

OK, I'll commit now and then stay out of your way.

regards, tom lane

#25Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#22)
Re: pgindent run coming

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I am unclear why struct pointers are not being formatted properly in
function headers but will research it.

Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do right now.

Have you started the pgindent run yet? I have a patch ready for
the cursor stability issue, but will hold off committing if it might
create a merge problem for you.

I am doing runs as requested on various platforms to extract the typedef
lists. Linux is done, Windows (mingw) is running, FBSD and Cygwin to come.

Results in a few hours. The buildfarm will have a consolidated list.

cheers

andrew

#26Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#25)
1 attachment(s)
Re: pgindent run coming

Andrew Dunstan wrote:

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

I am unclear why struct pointers are not being formatted properly in
function headers but will research it.

Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do right now.

Have you started the pgindent run yet? I have a patch ready for
the cursor stability issue, but will hold off committing if it might
create a merge problem for you.

I am doing runs as requested on various platforms to extract the typedef
lists. Linux is done, Windows (mingw) is running, FBSD and Cygwin to come.

Results in a few hours. The buildfarm will have a consolidated list.

OK, good. However, I am seeing missing typedefs in the Linux list you
posted at:

http://www.pgbuildfarm.org/cgi-bin/typedefs.pl

I pulled this list 20 minutes ago. I compared your list to the BSD list
I usually used and found that the Linux list had fewer typedefs:

2270 typedefs.old
1848 typedefs.new

I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:

typedef struct PortalData *Portal;

typedef struct PortalData
{
/* Bookkeeping data */
...
bool visible; /* include this portal in pg_cursors? */
} PortalData;

I will try to build on Linux here and see how objdump displays that,
unless you can get me the output.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachments:

/rtmp/difftext/x-diffDownload
#27Greg Stark
stark@enterprisedb.com
In reply to: Bruce Momjian (#26)
Re: pgindent run coming

Out of curiosity how different is the output if we don't pass the
typedef list at all? I'm wondering if the formatting differences are
things we actually care much about anyways.

#28Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#26)
Re: pgindent run coming

Bruce Momjian wrote:

I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:

typedef struct PortalData *Portal;

typedef struct PortalData
{
/* Bookkeeping data */
...
bool visible; /* include this portal in pg_cursors? */
} PortalData;

I will try to build on Linux here and see how objdump displays that,
unless you can get me the output.

Well, that is almost certainly a result of the change you asked me to
make :-)

The symbol is in the run done early this morning before those changes.
See
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dungbeetle&amp;dt=2009-06-10%20064401&amp;stg=typedefs&gt;

So we need to look and see what tag that symbol has in the objdump output.

cheers

andrew

#29Tom Lane
tgl@sss.pgh.pa.us
In reply to: Greg Stark (#27)
Re: pgindent run coming

Greg Stark <stark@enterprisedb.com> writes:

Out of curiosity how different is the output if we don't pass the
typedef list at all? I'm wondering if the formatting differences are
things we actually care much about anyways.

It tends to put extra spaces in variable declarations that are using
the typedef. Not sure about other effects, but it is kinda ugly when
you are used to it being right.

regards, tom lane

#30Peter Eisentraut
peter_e@gmx.net
In reply to: Bruce Momjian (#1)
Re: pgindent run coming

On Tuesday 09 June 2009 20:21:35 Bruce Momjian wrote:

It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
running it at zero-hour GMT tomorrow, meaning five hours from now.
Any objections?

Btw., can you make pgindent remove whitespace at the end of lines?

#31Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#30)
Re: pgindent run coming

Peter Eisentraut <peter_e@gmx.net> writes:

Btw., can you make pgindent remove whitespace at the end of lines?

I think it usually does that already ...

regards, tom lane

#32Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#28)
1 attachment(s)
Re: pgindent run coming

Andrew Dunstan wrote:

Bruce Momjian wrote:

I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:

typedef struct PortalData *Portal;

typedef struct PortalData
{
/* Bookkeeping data */
...
bool visible; /* include this portal in pg_cursors? */
} PortalData;

I will try to build on Linux here and see how objdump displays that,
unless you can get me the output.

Well, that is almost certainly a result of the change you asked me to
make :-)

The symbol is in the run done early this morning before those changes.
See
<http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dungbeetle&amp;dt=2009-06-10%20064401&amp;stg=typedefs&gt;

So we need to look and see what tag that symbol has in the objdump output.

OK, I got the answer for Linux. I built 8.4 RC2 and ran:

objdump -W postgres |grep -3 PortalData

and the output is attached. You will notice every mention of PortalData
has 'DW_TAG_structure_type' (stucture member) above it, and none have
DW_TAG_typedef (typedef tag). This is caused by this documented
behavior from find_typedef:

# Linux
# Unfortunately the Linux version doesn't show unreferenced typedefs.
# The problem is that they are still in the source code so should be
# indented properly. However, I think pgindent only cares about
# the typedef references, not the definitions, so I think it might
# be fine

So that is why the Linux list is shorter, but again, I think that is fine.
Andrew, let me know when your list is ready.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachments:

/rtmp/atext/plainDownload
#33Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#31)
Re: pgindent run coming

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Btw., can you make pgindent remove whitespace at the end of lines?

I think it usually does that already ...

Yes.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#34Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#29)
Re: pgindent run coming

Tom Lane wrote:

Greg Stark <stark@enterprisedb.com> writes:

Out of curiosity how different is the output if we don't pass the
typedef list at all? I'm wondering if the formatting differences are
things we actually care much about anyways.

It tends to put extra spaces in variable declarations that are using
the typedef. Not sure about other effects, but it is kinda ugly when
you are used to it being right.

Yea, I used a short pgindent typedef list once and people noticed right
away so I had to rerun.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#35Peter Eisentraut
peter_e@gmx.net
In reply to: Bruce Momjian (#33)
1 attachment(s)
Re: pgindent run coming

On Wednesday 10 June 2009 22:50:15 Bruce Momjian wrote:

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Btw., can you make pgindent remove whitespace at the end of lines?

I think it usually does that already ...

Yes.

Um, attached you will find a bunch of counterexamples.

Attachments:

whitespace.difftext/x-patch; charset=UTF-8; name=whitespace.diffDownload
Index: src/bin/initdb/initdb.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving revision 1.171
diff -u -3 -p -r1.171 initdb.c
--- src/bin/initdb/initdb.c	3 Jun 2009 16:17:49 -0000	1.171
+++ src/bin/initdb/initdb.c	10 Jun 2009 20:42:32 -0000
@@ -1356,9 +1356,9 @@ bootstrap_template1(char *short_version)
 	bki_lines = replace_token(bki_lines, "ENCODING", encodingid);
 
 	bki_lines = replace_token(bki_lines, "LC_COLLATE", lc_collate);
-	
+
 	bki_lines = replace_token(bki_lines, "LC_CTYPE", lc_ctype);
-	
+
 	/*
 	 * Pass correct LC_xxx environment to bootstrap.
 	 *
Index: src/bin/pg_ctl/pg_ctl.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_ctl/pg_ctl.c,v
retrieving revision 1.110
diff -u -3 -p -r1.110 pg_ctl.c
--- src/bin/pg_ctl/pg_ctl.c	5 Apr 2009 04:19:58 -0000	1.110
+++ src/bin/pg_ctl/pg_ctl.c	10 Jun 2009 20:42:32 -0000
@@ -1486,9 +1486,9 @@ CreateRestrictedProcess(char *cmd, PROCE
 	}
 
 #ifndef __CYGWIN__
-    AddUserToDacl(processInfo->hProcess);
+	AddUserToDacl(processInfo->hProcess);
 #endif
-    
+
 	CloseHandle(restrictedToken);
 
 	ResumeThread(processInfo->hThread);
Index: src/bin/pg_dump/dumputils.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/dumputils.c,v
retrieving revision 1.45
diff -u -3 -p -r1.45 dumputils.c
--- src/bin/pg_dump/dumputils.c	11 Mar 2009 03:33:29 -0000	1.45
+++ src/bin/pg_dump/dumputils.c	10 Jun 2009 20:42:33 -0000
@@ -59,7 +59,7 @@ init_parallel_dump_utils(void)
 const char *
 fmtId(const char *rawid)
 {
-	/* 
+	/*
 	 * The Tls code goes awry if we use a static var, so we provide for both
 	 * static and auto, and omit any use of the static var when using Tls.
 	 */
@@ -87,7 +87,7 @@ fmtId(const char *rawid)
 	{
 		/* new buffer */
 		id_return = createPQExpBuffer();
-#ifdef WIN32		
+#ifdef WIN32
 		if (parallel_init_done)
 			TlsSetValue(tls_index,id_return);
 		else
@@ -95,7 +95,7 @@ fmtId(const char *rawid)
 #else
 		s_id_return = id_return;
 #endif
-		
+
 	}
 
 	/*
Index: src/bin/pg_dump/keywords.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/keywords.c,v
retrieving revision 1.2
diff -u -3 -p -r1.2 keywords.c
--- src/bin/pg_dump/keywords.c	8 Mar 2009 16:53:30 -0000	1.2
+++ src/bin/pg_dump/keywords.c	10 Jun 2009 20:42:33 -0000
@@ -18,7 +18,7 @@
 #include "parser/keywords.h"
 
 /*
- * We don't need the token number, so leave it out to avoid requiring other 
+ * We don't need the token number, so leave it out to avoid requiring other
  * backend headers.
  */
 #define PG_KEYWORD(a,b,c) {a,0,c},
Index: src/bin/pg_dump/pg_backup_archiver.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_backup_archiver.c,v
retrieving revision 1.171
diff -u -3 -p -r1.171 pg_backup_archiver.c
--- src/bin/pg_dump/pg_backup_archiver.c	4 Jun 2009 19:16:48 -0000	1.171
+++ src/bin/pg_dump/pg_backup_archiver.c	10 Jun 2009 20:42:33 -0000
@@ -3487,12 +3487,12 @@ parallel_restore(RestoreArgs *args)
 
 	/*
 	 * Close and reopen the input file so we have a private file pointer
-	 * that doesn't stomp on anyone else's file pointer, if we're actually 
+	 * that doesn't stomp on anyone else's file pointer, if we're actually
 	 * going to need to read from the file. Otherwise, just close it
 	 * except on Windows, where it will possibly be needed by other threads.
 	 *
 	 * Note: on Windows, since we are using threads not processes, the
-	 * reopen call *doesn't* close the original file pointer but just open 
+	 * reopen call *doesn't* close the original file pointer but just open
 	 * a new one.
 	 */
 	if (te->section == SECTION_DATA )
@@ -3870,7 +3870,7 @@ CloneArchive(ArchiveHandle *AH)
 	ArchiveHandle *clone;
 
 	/* Make a "flat" copy */
-	clone = (ArchiveHandle *) malloc(sizeof(ArchiveHandle)); 
+	clone = (ArchiveHandle *) malloc(sizeof(ArchiveHandle));
 	if (clone == NULL)
 		die_horribly(AH, modulename, "out of memory\n");
 	memcpy(clone, AH, sizeof(ArchiveHandle));
Index: src/bin/pg_dump/pg_backup_custom.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_backup_custom.c,v
retrieving revision 1.41
diff -u -3 -p -r1.41 pg_backup_custom.c
--- src/bin/pg_dump/pg_backup_custom.c	2 Feb 2009 20:07:37 -0000	1.41
+++ src/bin/pg_dump/pg_backup_custom.c	10 Jun 2009 20:42:33 -0000
@@ -133,8 +133,8 @@ InitArchiveFmt_Custom(ArchiveHandle *AH)
 	AH->StartBlobPtr = _StartBlob;
 	AH->EndBlobPtr = _EndBlob;
 	AH->EndBlobsPtr = _EndBlobs;
-	AH->ClonePtr = _Clone;	
-	AH->DeClonePtr = _DeClone;	
+	AH->ClonePtr = _Clone;
+	AH->DeClonePtr = _DeClone;
 
 	/*
 	 * Set up some special context used in compressing data.
@@ -842,7 +842,7 @@ _CloseArchive(ArchiveHandle *AH)
  * is because on Windows, this is used within a multithreading context,
  * and we don't want a thread closing the parent file handle.)
  */
-static void 
+static void
 _ReopenArchive(ArchiveHandle *AH)
 {
 	lclContext *ctx = (lclContext *) AH->formatData;
@@ -858,12 +858,12 @@ _ReopenArchive(ArchiveHandle *AH)
 	errno = 0;
 	tpos = ftello(AH->FH);
 	if (errno)
-		die_horribly(AH, modulename, "could not determine seek position in archive file: %s\n", 
+		die_horribly(AH, modulename, "could not determine seek position in archive file: %s\n",
 					 strerror(errno));
 
 #ifndef WIN32
 	if (fclose(AH->FH) != 0)
-		die_horribly(AH, modulename, "could not close archive file: %s\n", 
+		die_horribly(AH, modulename, "could not close archive file: %s\n",
 					 strerror(errno));
 #endif
 
@@ -873,7 +873,7 @@ _ReopenArchive(ArchiveHandle *AH)
 					 AH->fSpec, strerror(errno));
 
 	if (fseeko(AH->FH, tpos, SEEK_SET) != 0)
-		die_horribly(AH, modulename, "could not set seek position in archive file: %s\n", 
+		die_horribly(AH, modulename, "could not set seek position in archive file: %s\n",
 					 strerror(errno));
 }
 
@@ -1096,7 +1096,7 @@ static void
 _DeClone(ArchiveHandle *AH)
 {
 	lclContext *ctx = (lclContext *) AH->formatData;
-	
+
 	free(ctx->zlibOut);
 	free(ctx->zlibIn);
 	free(ctx->zp);
Index: src/bin/pg_dump/pg_dump.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.538
diff -u -3 -p -r1.538 pg_dump.c
--- src/bin/pg_dump/pg_dump.c	27 May 2009 20:42:29 -0000	1.538
+++ src/bin/pg_dump/pg_dump.c	10 Jun 2009 20:42:34 -0000
@@ -1739,7 +1739,7 @@ dumpDatabase(Archive *AH)
 		appendStringLiteralAH(creaQry, datname, AH);
 		appendPQExpBuffer(creaQry, ";\n");
 	}
-	
+
 	appendPQExpBuffer(delQry, "DROP DATABASE %s;\n",
 					  fmtId(datname));
 
@@ -4815,7 +4815,7 @@ getTableAttrs(TableInfo *tblinfo, int nu
 					tbinfo->atttypnames[j] = strdup("TEXT");
 			}
 		}
-			
+
 		/*
 		 * Get info about column defaults
 		 */
@@ -9940,7 +9940,7 @@ dumpTableSchema(Archive *fout, TableInfo
 								 "(SELECT oid FROM pg_namespace "
 								 "WHERE nspname = CURRENT_SCHEMA);\n");
 		}
-	
+
 		/* Loop dumping statistics and storage statements */
 		for (j = 0; j < tbinfo->numatts; j++)
 		{
Index: src/bin/pg_dump/pg_dumpall.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_dumpall.c,v
retrieving revision 1.125
diff -u -3 -p -r1.125 pg_dumpall.c
--- src/bin/pg_dump/pg_dumpall.c	10 May 2009 02:51:44 -0000	1.125
+++ src/bin/pg_dump/pg_dumpall.c	10 Jun 2009 20:42:35 -0000
@@ -279,7 +279,7 @@ main(int argc, char *argv[])
 					disable_dollar_quoting = 1;
 				else if (strcmp(optarg, "disable-triggers") == 0)
 					disable_triggers = 1;
-				else if (strcmp(optarg, "no-tablespaces") == 0) 
+				else if (strcmp(optarg, "no-tablespaces") == 0)
 					no_tablespaces = 1;
 				else if (strcmp(optarg, "use-set-session-authorization") == 0)
 					use_setsessauth = 1;
Index: src/bin/pg_dump/pg_restore.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_restore.c,v
retrieving revision 1.99
diff -u -3 -p -r1.99 pg_restore.c
--- src/bin/pg_dump/pg_restore.c	14 Apr 2009 00:06:35 -0000	1.99
+++ src/bin/pg_dump/pg_restore.c	10 Jun 2009 20:42:35 -0000
@@ -278,9 +278,9 @@ main(int argc, char **argv)
 				break;
 
 			case 0:
-				/* 
-				 * This covers the long options without a short equivalent, 
-				 * including those equivalent to -X xxx. 
+				/*
+				 * This covers the long options without a short equivalent,
+				 * including those equivalent to -X xxx.
 				 */
 				break;
 
Index: src/bin/psql/command.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.205
diff -u -3 -p -r1.205 command.c
--- src/bin/psql/command.c	21 Apr 2009 15:49:06 -0000	1.205
+++ src/bin/psql/command.c	10 Jun 2009 20:42:35 -0000
@@ -1341,7 +1341,7 @@ connection_warnings(void)
 				server_version = server_ver_str;
 			}
 
-			printf(_("%s (%s, server %s)\n"), 
+			printf(_("%s (%s, server %s)\n"),
 			pset.progname, PG_VERSION, server_version);
 		}
 		else
Index: src/bin/psql/describe.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.214
diff -u -3 -p -r1.214 describe.c
--- src/bin/psql/describe.c	4 Jun 2009 19:17:39 -0000	1.214
+++ src/bin/psql/describe.c	10 Jun 2009 20:42:35 -0000
@@ -811,7 +811,7 @@ objectDescription(const char *pattern, b
  	if (!showSystem && !pattern)
  		appendPQExpBuffer(&buf, "WHERE n.nspname <> 'pg_catalog'\n"
  								"      AND n.nspname <> 'information_schema'\n");
- 
+
 	processSQLNamePattern(pset.db, &buf, pattern, !showSystem && !pattern, false,
 						  "n.nspname", "o.oprname", NULL,
 						  "pg_catalog.pg_operator_is_visible(o.oid)");
@@ -1123,7 +1123,7 @@ describeOneTableDetails(const char *sche
 								atooid(PQgetvalue(res, 0, 7)) : 0;
 	PQclear(res);
 	res = NULL;
-	
+
 	/*
 	 * If it's a sequence, fetch its values and store into an
 	 * array that will be used later.
@@ -1131,7 +1131,7 @@ describeOneTableDetails(const char *sche
 	if (tableinfo.relkind == 'S')
 	{
 		PGresult   *result;
-		
+
 #define SEQ_NUM_COLS 10
 		printfPQExpBuffer(&buf,
 						  "SELECT sequence_name, last_value,\n"
@@ -1142,16 +1142,16 @@ describeOneTableDetails(const char *sche
 						  fmtId(schemaname));
 		/* must be separate because fmtId isn't reentrant */
 		appendPQExpBuffer(&buf, ".%s", fmtId(relationname));
-		
+
 		result = PSQLexec(buf.data, false);
 		if (!result)
 			goto error_return;
-		
+
 		seq_values = pg_malloc_zero((SEQ_NUM_COLS+1) * sizeof(*seq_values));
-		
-		for (i = 0; i < SEQ_NUM_COLS; i++) 
+
+		for (i = 0; i < SEQ_NUM_COLS; i++)
 			seq_values[i] = pg_strdup(PQgetvalue(result, 0, i));
-		
+
 		PQclear(result);
 	}
 
@@ -1230,13 +1230,13 @@ describeOneTableDetails(const char *sche
 
 	if (tableinfo.relkind == 'S')
 		headers[cols++] = gettext_noop("Value");
-		
+
 	if (verbose)
 	{
 		headers[cols++] = gettext_noop("Storage");
 		headers[cols++] = gettext_noop("Description");
 	}
-	
+
 	printTableInit(&cont, &myopt, title.data, cols, numrows);
 	printTableInitialized = true;
 
@@ -1851,14 +1851,14 @@ error_return:
 	termPQExpBuffer(&buf);
 	termPQExpBuffer(&title);
 	termPQExpBuffer(&tmpbuf);
-	
+
 	if (seq_values)
 	{
 		for (ptr = seq_values; *ptr; ptr++)
 			free(*ptr);
 		free(seq_values);
 	}
-    
+
 	if (modifiers)
 	{
 		for (ptr = modifiers; *ptr; ptr++)
Index: src/bin/psql/print.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/print.c,v
retrieving revision 1.114
diff -u -3 -p -r1.114 print.c
--- src/bin/psql/print.c	4 Jun 2009 19:17:39 -0000	1.114
+++ src/bin/psql/print.c	10 Jun 2009 20:42:36 -0000
@@ -520,7 +520,7 @@ print_aligned_text(const printTableConte
 	if (col_count != 0 && cell_count != 0)
 	{
 		int rows = cell_count / col_count;
-		
+
 		for (i = 0; i < col_count; i++)
 			width_average[i] /= rows;
 	}
@@ -640,7 +640,7 @@ print_aligned_text(const printTableConte
 		fout = PageOutput(INT_MAX, cont->opt->pager);	/* force pager */
 		is_pager = true;
 	}
-	
+
 	/* Check if newlines or our wrapping now need the pager */
 	if (!is_pager)
 	{
@@ -650,12 +650,12 @@ print_aligned_text(const printTableConte
 			int			width,
 						nl_lines,
 						bytes_required;
-	
+
 			pg_wcssize((unsigned char *) *ptr, strlen(*ptr), encoding,
 					   &width, &nl_lines, &bytes_required);
 			if (opt_numeric_locale && cont->align[i] == 'r')
 				width += additional_numeric_locale_len(*ptr);
-	
+
 			/*
 			 *	A row can have both wrapping and newlines that cause
 			 *	it to display across multiple lines.  We check
@@ -681,7 +681,7 @@ print_aligned_text(const printTableConte
 		}
 		IsPagerNeeded(cont, extra_output_lines, &fout, &is_pager);
 	}
-	
+
 	/* time to output */
 	if (cont->opt->start_table)
 	{
@@ -2208,7 +2208,7 @@ void
 printTable(const printTableContent *cont, FILE *fout, FILE *flog)
 {
 	bool		is_pager = false;
-	
+
 	if (cancel_pressed)
 		return;
 
@@ -2412,11 +2412,11 @@ strlen_max_width(unsigned char *str, int
 			break;
 
 		curr_width += char_width;
-			
+
 		str += PQmblen((char *) str, encoding);
 	}
 
 	*target_width = curr_width;
-	
+
 	return str - start;
 }
Index: src/bin/psql/print.h
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/print.h,v
retrieving revision 1.39
diff -u -3 -p -r1.39 print.h
--- src/bin/psql/print.h	1 Jan 2009 17:23:55 -0000	1.39
+++ src/bin/psql/print.h	10 Jun 2009 20:42:36 -0000
@@ -103,13 +103,13 @@ extern void html_escaped_print(const cha
 extern void printTableInit(printTableContent *const content,
 				const printTableOpt *opt, const char *title,
 				const int ncolumns, const int nrows);
-extern void printTableAddHeader(printTableContent *const content, 
+extern void printTableAddHeader(printTableContent *const content,
 				const char *header, const bool translate, const char align);
-extern void printTableAddCell(printTableContent *const content, 
+extern void printTableAddCell(printTableContent *const content,
 				const char *cell, const bool translate);
-extern void printTableAddFooter(printTableContent *const content, 
+extern void printTableAddFooter(printTableContent *const content,
 				const char *footer);
-extern void printTableSetFooter(printTableContent *const content, 
+extern void printTableSetFooter(printTableContent *const content,
 				const char *footer);
 extern void printTableCleanup(printTableContent *const content);
 extern void printTable(const printTableContent *cont, FILE *fout, FILE *flog);
Index: src/include/c.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/c.h,v
retrieving revision 1.235
diff -u -3 -p -r1.235 c.h
--- src/include/c.h	26 Mar 2009 22:26:07 -0000	1.235
+++ src/include/c.h	10 Jun 2009 20:42:36 -0000
@@ -842,7 +842,7 @@ extern int	fdatasync(int fildes);
 #if defined(HAVE_WCSTOMBS) && defined(HAVE_TOWLOWER)
 #define USE_WIDE_UPPER_LOWER
 #endif
-   
+
 /* EXEC_BACKEND defines */
 #ifdef EXEC_BACKEND
 #define NON_EXEC_STATIC
Index: src/include/miscadmin.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/miscadmin.h,v
retrieving revision 1.210
diff -u -3 -p -r1.210 miscadmin.h
--- src/include/miscadmin.h	5 May 2009 19:59:00 -0000	1.210
+++ src/include/miscadmin.h	10 Jun 2009 20:42:36 -0000
@@ -192,7 +192,7 @@ extern PGDLLIMPORT Oid MyDatabaseTableSp
 
 extern int	DateStyle;
 extern int	DateOrder;
- 
+
 /*
  * IntervalStyles
  *   INTSTYLE_POSTGRES             Like Postgres < 8.4 when DateStyle = 'iso'
Index: src/include/port.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port.h,v
retrieving revision 1.124
diff -u -3 -p -r1.124 port.h
--- src/include/port.h	7 Jan 2009 03:39:33 -0000	1.124
+++ src/include/port.h	10 Jun 2009 20:42:36 -0000
@@ -281,7 +281,7 @@ extern void copydir(char *fromdir, char 
 
 extern bool rmtree(const char *path, bool rmtopdir);
 
-/* 
+/*
  * stat() is not guaranteed to set the st_size field on win32, so we
  * redefine it to our own implementation that is.
  *
Index: src/include/access/clog.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/access/clog.h,v
retrieving revision 1.23
diff -u -3 -p -r1.23 clog.h
--- src/include/access/clog.h	1 Jan 2009 17:23:55 -0000	1.23
+++ src/include/access/clog.h	10 Jun 2009 20:42:36 -0000
@@ -32,7 +32,7 @@ typedef int XidStatus;
 #define NUM_CLOG_BUFFERS	8
 
 
-extern void TransactionIdSetTreeStatus(TransactionId xid, int nsubxids, 
+extern void TransactionIdSetTreeStatus(TransactionId xid, int nsubxids,
 					TransactionId *subxids, XidStatus status, XLogRecPtr lsn);
 extern XidStatus TransactionIdGetStatus(TransactionId xid, XLogRecPtr *lsn);
 
Index: src/include/access/nbtree.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/access/nbtree.h,v
retrieving revision 1.123
diff -u -3 -p -r1.123 nbtree.h
--- src/include/access/nbtree.h	1 Jan 2009 17:23:56 -0000	1.123
+++ src/include/access/nbtree.h	10 Jun 2009 20:42:36 -0000
@@ -287,7 +287,7 @@ typedef struct xl_btree_split
 	 * than BlockNumber for alignment reasons: SizeOfBtreeSplit is only 16-bit
 	 * aligned.)
 	 *
-	 * If level > 0, an IndexTuple representing the HIKEY of the left page 
+	 * If level > 0, an IndexTuple representing the HIKEY of the left page
 	 * follows.  We don't need this on leaf pages, because it's the same
 	 * as the leftmost key in the new right page.  Also, it's suppressed if
 	 * XLogInsert chooses to store the left page's whole page image.
Index: src/include/catalog/genbki.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/catalog/genbki.h,v
retrieving revision 1.2
diff -u -3 -p -r1.2 genbki.h
--- src/include/catalog/genbki.h	1 Jan 2009 17:23:56 -0000	1.2
+++ src/include/catalog/genbki.h	10 Jun 2009 20:42:36 -0000
@@ -16,7 +16,7 @@
  *
  *-------------------------------------------------------------------------
  */
-#ifndef GENBKI_H 
+#ifndef GENBKI_H
 #define GENBKI_H
 
 /* Introduces a catalog's structure definition */
Index: src/include/commands/comment.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/commands/comment.h,v
retrieving revision 1.23
diff -u -3 -p -r1.23 comment.h
--- src/include/commands/comment.h	1 Jan 2009 17:23:58 -0000	1.23
+++ src/include/commands/comment.h	10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/include/commands/comment.h,v 1.23 2009/01/01 17:23:58 momjian Exp $ 
+ * $PostgreSQL: pgsql/src/include/commands/comment.h,v 1.23 2009/01/01 17:23:58 momjian Exp $
  *
  *-------------------------------------------------------------------------
  *
Index: src/include/commands/proclang.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/commands/proclang.h,v
retrieving revision 1.14
diff -u -3 -p -r1.14 proclang.h
--- src/include/commands/proclang.h	17 May 2008 01:28:24 -0000	1.14
+++ src/include/commands/proclang.h	10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/include/commands/proclang.h,v 1.14 2008/05/17 01:28:24 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/commands/proclang.h,v 1.14 2008/05/17 01:28:24 adunstan Exp $
  *
  *-------------------------------------------------------------------------
  *
Index: src/include/commands/trigger.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/commands/trigger.h,v
retrieving revision 1.72
diff -u -3 -p -r1.72 trigger.h
--- src/include/commands/trigger.h	22 Jan 2009 20:16:09 -0000	1.72
+++ src/include/commands/trigger.h	10 Jun 2009 20:42:36 -0000
@@ -39,7 +39,7 @@ typedef struct TriggerData
 } TriggerData;
 
 /*
- * TriggerEvent bit flags 
+ * TriggerEvent bit flags
  *
  * Note that we assume different event types (INSERT/DELETE/UPDATE/TRUNCATE)
  * can't be OR'd together in a single TriggerEvent.  This is unlike the
Index: src/include/libpq/hba.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/libpq/hba.h,v
retrieving revision 1.55
diff -u -3 -p -r1.55 hba.h
--- src/include/libpq/hba.h	7 Jan 2009 13:09:21 -0000	1.55
+++ src/include/libpq/hba.h	10 Jun 2009 20:42:36 -0000
@@ -38,7 +38,7 @@ typedef enum ConnType
 	ctHostNoSSL
 } ConnType;
 
-typedef struct 
+typedef struct
 {
 	int			linenumber;
 	ConnType	conntype;
Index: src/include/nodes/execnodes.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/nodes/execnodes.h,v
retrieving revision 1.204
diff -u -3 -p -r1.204 execnodes.h
--- src/include/nodes/execnodes.h	8 Apr 2009 21:51:38 -0000	1.204
+++ src/include/nodes/execnodes.h	10 Jun 2009 20:42:36 -0000
@@ -18,8 +18,8 @@
 #include "access/heapam.h"
 #include "access/skey.h"
 #include "nodes/params.h"
-#include "nodes/plannodes.h"    
-#include "nodes/tidbitmap.h"    
+#include "nodes/plannodes.h"
+#include "nodes/tidbitmap.h"
 #include "utils/hsearch.h"
 #include "utils/rel.h"
 #include "utils/snapshot.h"
Index: src/include/port/aix.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/aix.h,v
retrieving revision 1.12
diff -u -3 -p -r1.12 aix.h
--- src/include/port/aix.h	17 May 2008 01:28:24 -0000	1.12
+++ src/include/port/aix.h	10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/include/port/aix.h,v 1.12 2008/05/17 01:28:24 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/port/aix.h,v 1.12 2008/05/17 01:28:24 adunstan Exp $
  */
 #define CLASS_CONFLICT
 #define DISABLE_XOPEN_NLS
Index: src/include/port/bsdi.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/bsdi.h,v
retrieving revision 1.14
diff -u -3 -p -r1.14 bsdi.h
--- src/include/port/bsdi.h	17 May 2008 01:28:24 -0000	1.14
+++ src/include/port/bsdi.h	10 Jun 2009 20:42:36 -0000
@@ -1,4 +1,4 @@
 /*
- * $PostgreSQL: pgsql/src/include/port/bsdi.h,v 1.14 2008/05/17 01:28:24 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/port/bsdi.h,v 1.14 2008/05/17 01:28:24 adunstan Exp $
  */
 
Index: src/include/port/sco.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/sco.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 sco.h
--- src/include/port/sco.h	17 May 2008 01:28:24 -0000	1.18
+++ src/include/port/sco.h	10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/include/port/sco.h,v 1.18 2008/05/17 01:28:24 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/port/sco.h,v 1.18 2008/05/17 01:28:24 adunstan Exp $
  *
  * see src/backend/libpq/pqcomm.c */
 #define SCO_ACCEPT_BUG
Index: src/include/port/sunos4.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/sunos4.h,v
retrieving revision 1.11
diff -u -3 -p -r1.11 sunos4.h
--- src/include/port/sunos4.h	11 Dec 2008 09:17:07 -0000	1.11
+++ src/include/port/sunos4.h	10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/include/port/sunos4.h,v 1.11 2008/12/11 09:17:07 petere Exp $ 
+ * $PostgreSQL: pgsql/src/include/port/sunos4.h,v 1.11 2008/12/11 09:17:07 petere Exp $
  *
  * sprintf() returns char *, not int, on SunOS 4.1.x */
 #define SPRINTF_CHAR
Index: src/include/port/ultrix4.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/ultrix4.h,v
retrieving revision 1.12
diff -u -3 -p -r1.12 ultrix4.h
--- src/include/port/ultrix4.h	17 May 2008 01:28:24 -0000	1.12
+++ src/include/port/ultrix4.h	10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/include/port/ultrix4.h,v 1.12 2008/05/17 01:28:24 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/port/ultrix4.h,v 1.12 2008/05/17 01:28:24 adunstan Exp $
  */
 #define NOFIXADE
 #define NEED_STRDUP
Index: src/include/port/univel.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/univel.h,v
retrieving revision 1.24
diff -u -3 -p -r1.24 univel.h
--- src/include/port/univel.h	17 May 2008 01:28:24 -0000	1.24
+++ src/include/port/univel.h	10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/include/port/univel.h,v 1.24 2008/05/17 01:28:24 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/port/univel.h,v 1.24 2008/05/17 01:28:24 adunstan Exp $
  *
  ***************************************
  * Define this if you are compiling with
Index: src/include/port/unixware.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/unixware.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 unixware.h
--- src/include/port/unixware.h	17 May 2008 01:28:24 -0000	1.18
+++ src/include/port/unixware.h	10 Jun 2009 20:42:36 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/include/port/unixware.h,v 1.18 2008/05/17 01:28:24 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/port/unixware.h,v 1.18 2008/05/17 01:28:24 adunstan Exp $
  *
  * see src/backend/libpq/pqcomm.c */
 #define SCO_ACCEPT_BUG
Index: src/include/port/win32/pwd.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/win32/pwd.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 pwd.h
--- src/include/port/win32/pwd.h	17 May 2008 01:28:25 -0000	1.3
+++ src/include/port/win32/pwd.h	10 Jun 2009 20:42:36 -0000
@@ -1,4 +1,4 @@
 /*
- * $PostgreSQL: pgsql/src/include/port/win32/pwd.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/port/win32/pwd.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $
  */
 
Index: src/include/port/win32/sys/wait.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/port/win32/sys/wait.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 wait.h
--- src/include/port/win32/sys/wait.h	17 May 2008 01:28:25 -0000	1.3
+++ src/include/port/win32/sys/wait.h	10 Jun 2009 20:42:37 -0000
@@ -1,4 +1,4 @@
 /*
- * $PostgreSQL: pgsql/src/include/port/win32/sys/wait.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/port/win32/sys/wait.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $
  */
 
Index: src/include/storage/bufmgr.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/storage/bufmgr.h,v
retrieving revision 1.120
diff -u -3 -p -r1.120 bufmgr.h
--- src/include/storage/bufmgr.h	12 Jan 2009 05:10:45 -0000	1.120
+++ src/include/storage/bufmgr.h	10 Jun 2009 20:42:37 -0000
@@ -189,7 +189,7 @@ extern void DropDatabaseBuffers(Oid dbid
 extern void PrintPinnedBufs(void);
 #endif
 extern Size BufferShmemSize(void);
-extern void BufferGetTag(Buffer buffer, RelFileNode *rnode, 
+extern void BufferGetTag(Buffer buffer, RelFileNode *rnode,
 						 ForkNumber *forknum, BlockNumber *blknum);
 
 extern void SetBufferCommitInfoNeedsSave(Buffer buffer);
Index: src/include/storage/s_lock.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/storage/s_lock.h,v
retrieving revision 1.166
diff -u -3 -p -r1.166 s_lock.h
--- src/include/storage/s_lock.h	1 Jan 2009 17:24:01 -0000	1.166
+++ src/include/storage/s_lock.h	10 Jun 2009 20:42:37 -0000
@@ -815,7 +815,7 @@ spin_delay(void)
 
 #endif
 
-  
+
 #endif	/* !defined(HAS_TEST_AND_SET) */
 
 
Index: src/include/storage/sinvaladt.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/storage/sinvaladt.h,v
retrieving revision 1.50
diff -u -3 -p -r1.50 sinvaladt.h
--- src/include/storage/sinvaladt.h	1 Jan 2009 17:24:01 -0000	1.50
+++ src/include/storage/sinvaladt.h	10 Jun 2009 20:42:37 -0000
@@ -8,7 +8,7 @@
  * must be delivered to all already-running backends before it can be
  * forgotten.  (If we run out of space, we instead deliver a "RESET"
  * message to backends that have fallen too far behind.)
- * 
+ *
  * The struct type SharedInvalidationMessage, defining the contents of
  * a single message, is defined in sinval.h.
  *
Index: src/include/storage/smgr.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/storage/smgr.h,v
retrieving revision 1.66
diff -u -3 -p -r1.66 smgr.h
--- src/include/storage/smgr.h	12 Jan 2009 05:10:45 -0000	1.66
+++ src/include/storage/smgr.h	10 Jun 2009 20:42:37 -0000
@@ -68,7 +68,7 @@ extern void smgrclosenode(RelFileNode rn
 extern void smgrcreate(SMgrRelation reln, ForkNumber forknum, bool isRedo);
 extern void smgrdounlink(SMgrRelation reln, ForkNumber forknum,
 						 bool isTemp, bool isRedo);
-extern void smgrextend(SMgrRelation reln, ForkNumber forknum, 
+extern void smgrextend(SMgrRelation reln, ForkNumber forknum,
 					   BlockNumber blocknum, char *buffer, bool isTemp);
 extern void smgrprefetch(SMgrRelation reln, ForkNumber forknum,
 						 BlockNumber blocknum);
Index: src/include/tsearch/ts_public.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/tsearch/ts_public.h,v
retrieving revision 1.13
diff -u -3 -p -r1.13 ts_public.h
--- src/include/tsearch/ts_public.h	15 Jan 2009 16:33:59 -0000	1.13
+++ src/include/tsearch/ts_public.h	10 Jun 2009 20:42:37 -0000
@@ -56,7 +56,7 @@ typedef struct
 	char	   *fragdelim;
 	int2		startsellen;
 	int2		stopsellen;
-	int2		fragdelimlen;         
+	int2		fragdelimlen;
 } HeadlineParsedText;
 
 /*
Index: src/include/utils/cash.h
===================================================================
RCS file: /cvsroot/pgsql/src/include/utils/cash.h,v
retrieving revision 1.26
diff -u -3 -p -r1.26 cash.h
--- src/include/utils/cash.h	17 May 2008 01:28:25 -0000	1.26
+++ src/include/utils/cash.h	10 Jun 2009 20:42:37 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/include/utils/cash.h,v 1.26 2008/05/17 01:28:25 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/include/utils/cash.h,v 1.26 2008/05/17 01:28:25 adunstan Exp $
  *
  *
  * cash.h
Index: src/interfaces/ecpg/ecpglib/connect.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/ecpglib/connect.c,v
retrieving revision 1.53
diff -u -3 -p -r1.53 connect.c
--- src/interfaces/ecpg/ecpglib/connect.c	15 Jan 2009 11:52:55 -0000	1.53
+++ src/interfaces/ecpg/ecpglib/connect.c	10 Jun 2009 20:42:37 -0000
@@ -497,7 +497,7 @@ ECPGconnect(int lineno, int c, const cha
 			 user ? "user=" : "", user ? user : "",
 			 passwd ? "password=" : "", passwd ? passwd : "",
 			 options ? options : "");
-	
+
 	/* this is deprecated
 	 * this->connection = PQsetdbLogin(host, port, options, NULL, realname, user, passwd);*/
 	this->connection = PQconnectdb(connect_string);
@@ -594,7 +594,7 @@ PGconn* ECPGget_PGconn(const char *conne
 	struct connection * con;
 
 	con=ecpg_get_connection(connection_name);
-	if (con==NULL) return NULL;    
+	if (con==NULL) return NULL;
 
 	return con->connection;
 }
Index: src/interfaces/ecpg/ecpglib/error.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/ecpglib/error.c,v
retrieving revision 1.22
diff -u -3 -p -r1.22 error.c
--- src/interfaces/ecpg/ecpglib/error.c	16 Jan 2009 09:15:03 -0000	1.22
+++ src/interfaces/ecpg/ecpglib/error.c	10 Jun 2009 20:42:37 -0000
@@ -21,56 +21,56 @@ ecpg_raise(int line, int code, const cha
 	{
 		case ECPG_NOT_FOUND:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("no data found on line %d"), line);
 			break;
 
 		case ECPG_OUT_OF_MEMORY:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("out of memory on line %d"), line);
 			break;
 
 		case ECPG_UNSUPPORTED:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("unsupported type \"%s\" on line %d"), str, line);
 			break;
 
 		case ECPG_TOO_MANY_ARGUMENTS:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("too many arguments on line %d"), line);
 			break;
 
 		case ECPG_TOO_FEW_ARGUMENTS:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("too few arguments on line %d"), line);
 			break;
 
 		case ECPG_INT_FORMAT:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("invalid input syntax for type int: \"%s\", on line %d"), str, line);
 			break;
 
 		case ECPG_UINT_FORMAT:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("invalid input syntax for type unsigned int: \"%s\", on line %d"), str, line);
 			break;
 
 		case ECPG_FLOAT_FORMAT:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("invalid input syntax for floating-point type: \"%s\", on line %d"), str, line);
 			break;
@@ -78,124 +78,124 @@ ecpg_raise(int line, int code, const cha
 		case ECPG_CONVERT_BOOL:
 			if (str)
 				snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-						 /* translator: this string will be truncated at 149 
+						 /* translator: this string will be truncated at 149
 							characters expanded.  */
 						 ecpg_gettext("invalid syntax for type boolean: \"%s\", on line %d"), str, line);
 			else
 				snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-						 /* translator: this string will be truncated at 149 
+						 /* translator: this string will be truncated at 149
 							characters expanded.  */
 						 ecpg_gettext("could not convert boolean value: size mismatch, on line %d"), line);
 			break;
 
 		case ECPG_EMPTY:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("empty query on line %d"), line);
 			break;
 
 		case ECPG_MISSING_INDICATOR:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("null value without indicator on line %d"), line);
 			break;
 
 		case ECPG_NO_ARRAY:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("variable does not have an array type on line %d"), line);
 			break;
 
 		case ECPG_DATA_NOT_ARRAY:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 					 ecpg_gettext("data read from server is not an array on line %d"), line);
 			break;
 
 		case ECPG_ARRAY_INSERT:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("inserting an array of variables is not supported on line %d"), line);
 			break;
 
 		case ECPG_NO_CONN:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("connection \"%s\" does not exist on line %d"), str, line);
 			break;
 
 		case ECPG_NOT_CONN:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("not connected to connection \"%s\" on line %d"), str, line);
 			break;
 
 		case ECPG_INVALID_STMT:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("invalid statement name \"%s\" on line %d"), str, line);
 			break;
 
 		case ECPG_UNKNOWN_DESCRIPTOR:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("descriptor \"%s\" not found on line %d"), str, line);
 			break;
 
 		case ECPG_INVALID_DESCRIPTOR_INDEX:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("descriptor index out of range on line %d"), line);
 			break;
 
 		case ECPG_UNKNOWN_DESCRIPTOR_ITEM:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("unrecognized descriptor item \"%s\" on line %d"), str, line);
 			break;
 
 		case ECPG_VAR_NOT_NUMERIC:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("variable does not have a numeric type on line %d"), line);
 			break;
 
 		case ECPG_VAR_NOT_CHAR:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("variable does not have a character type on line %d"), line);
 			break;
 
 		case ECPG_TRANS:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("error in transaction processing on line %d"), line);
 			break;
 
 		case ECPG_CONNECT:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				  ecpg_gettext("could not connect to database \"%s\" on line %d"), str, line);
 			break;
 
 		default:
 			snprintf(sqlca->sqlerrm.sqlerrmc, sizeof(sqlca->sqlerrm.sqlerrmc),
-				/* translator: this string will be truncated at 149 
+				/* translator: this string will be truncated at 149
 				   characters expanded.  */
 				 ecpg_gettext("SQL error %d on line %d"), code, line);
 			break;
Index: src/interfaces/ecpg/ecpglib/execute.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/ecpglib/execute.c,v
retrieving revision 1.84
diff -u -3 -p -r1.84 execute.c
--- src/interfaces/ecpg/ecpglib/execute.c	20 May 2009 16:49:23 -0000	1.84
+++ src/interfaces/ecpg/ecpglib/execute.c	10 Jun 2009 20:42:37 -0000
@@ -353,7 +353,7 @@ ecpg_store_result(const PGresult *result
 	{
 		int			len = 0;
 
-		if (!PQfformat(results, act_field)) 
+		if (!PQfformat(results, act_field))
 		{
 			switch (var->type)
 			{
@@ -1193,7 +1193,7 @@ ecpg_execute(struct statement * stmt)
 			return false;
 		}
 
-		/* 
+		/*
 		 * if var->type=ECPGt_char_variable we have a dynamic cursor we have
 		 * to simulate a dynamic cursor because there is no backend
 		 * functionality for it
@@ -1213,7 +1213,7 @@ ecpg_execute(struct statement * stmt)
 		 * if the placeholder is '$0' we have to replace it on the client side
 		 * this is for places we want to support variables at that are not supported in the backend
 		 */
-		else if (stmt->command[position] == '0' ) 
+		else if (stmt->command[position] == '0' )
 		{
 			if (!insert_tobeinserted(position, 2, stmt, tobeinserted))
 			{
Index: src/interfaces/ecpg/include/decimal.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/include/decimal.h,v
retrieving revision 1.18
diff -u -3 -p -r1.18 decimal.h
--- src/interfaces/ecpg/include/decimal.h	17 Feb 2008 18:14:29 -0000	1.18
+++ src/interfaces/ecpg/include/decimal.h	10 Jun 2009 20:42:37 -0000
@@ -6,7 +6,7 @@
 #include <ecpg_informix.h>
 
 #ifndef _ECPGLIB_H /* source created by ecpg which defines this symbol */
-typedef decimal dec_t; 
+typedef decimal dec_t;
 #endif /* ndef _ECPGLIB_H */
 
 #endif   /* ndef _ECPG_DECIMAL_H */
Index: src/interfaces/ecpg/include/sqlda.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/include/sqlda.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 sqlda.h
--- src/interfaces/ecpg/include/sqlda.h	17 May 2008 01:28:25 -0000	1.3
+++ src/interfaces/ecpg/include/sqlda.h	10 Jun 2009 20:42:37 -0000
@@ -1,4 +1,4 @@
 /*
- * $PostgreSQL: pgsql/src/interfaces/ecpg/include/sqlda.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/interfaces/ecpg/include/sqlda.h,v 1.3 2008/05/17 01:28:25 adunstan Exp $
  */
 
Index: src/interfaces/ecpg/include/sqltypes.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/include/sqltypes.h,v
retrieving revision 1.8
diff -u -3 -p -r1.8 sqltypes.h
--- src/interfaces/ecpg/include/sqltypes.h	17 May 2008 01:28:25 -0000	1.8
+++ src/interfaces/ecpg/include/sqltypes.h	10 Jun 2009 20:42:37 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/interfaces/ecpg/include/sqltypes.h,v 1.8 2008/05/17 01:28:25 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/interfaces/ecpg/include/sqltypes.h,v 1.8 2008/05/17 01:28:25 adunstan Exp $
  */
 #ifndef ECPG_SQLTYPES_H
 #define ECPG_SQLTYPES_H
Index: src/interfaces/ecpg/pgtypeslib/interval.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/interval.c,v
retrieving revision 1.40
diff -u -3 -p -r1.40 interval.c
--- src/interfaces/ecpg/pgtypeslib/interval.c	20 May 2009 16:13:18 -0000	1.40
+++ src/interfaces/ecpg/pgtypeslib/interval.c	10 Jun 2009 20:42:37 -0000
@@ -28,7 +28,7 @@ strtoi(const char *nptr, char **endptr, 
 	return (int) val;
 }
 
-/* copy&pasted from .../src/backend/utils/adt/datetime.c 
+/* copy&pasted from .../src/backend/utils/adt/datetime.c
  * and changesd struct pg_tm to struct tm
  */
 static void
@@ -50,7 +50,7 @@ AdjustFractSeconds(double frac, struct /
 }
 
 
-/* copy&pasted from .../src/backend/utils/adt/datetime.c 
+/* copy&pasted from .../src/backend/utils/adt/datetime.c
  * and changesd struct pg_tm to struct tm
  */
 static void
@@ -103,10 +103,10 @@ ISO8601IntegerWidth(char *fieldstart)
 }
 
 
-/* copy&pasted from .../src/backend/utils/adt/datetime.c 
+/* copy&pasted from .../src/backend/utils/adt/datetime.c
  * and changesd struct pg_tm to struct tm
  */
-static inline void 
+static inline void
 ClearPgTm(struct /*pg_*/tm *tm, fsec_t *fsec)
 {
 	tm->tm_year = 0;
@@ -118,10 +118,10 @@ ClearPgTm(struct /*pg_*/tm *tm, fsec_t *
 	*fsec       = 0;
 }
 
-/* copy&pasted from .../src/backend/utils/adt/datetime.c 
- * 
+/* copy&pasted from .../src/backend/utils/adt/datetime.c
+ *
  * * changesd struct pg_tm to struct tm
- * 
+ *
  * * Made the function static
  */
 static int
@@ -231,7 +231,7 @@ DecodeISO8601Interval(char *str,
 					if (*str != '-')
 						return DTERR_BAD_FORMAT;
 					str++;
-					
+
 					dterr = ParseISO8601Number(str, &str, &val, &fval);
 					if (dterr)
 						return dterr;
@@ -285,7 +285,7 @@ DecodeISO8601Interval(char *str,
 					AdjustFractSeconds(fval, tm, fsec, SECS_PER_HOUR);
 					if (unit == '\0')
 						return 0;
-					
+
 					dterr = ParseISO8601Number(str, &str, &val, &fval);
 					if (dterr)
 						return dterr;
@@ -296,7 +296,7 @@ DecodeISO8601Interval(char *str,
 					if (*str != ':')
 						return DTERR_BAD_FORMAT;
 					str++;
-					
+
 					dterr = ParseISO8601Number(str, &str, &val, &fval);
 					if (dterr)
 						return dterr;
@@ -791,7 +791,7 @@ AppendSeconds(char *cp, int sec, fsec_t 
 
 
 /* copy&pasted from .../src/backend/utils/adt/datetime.c
- * 
+ *
  * Change pg_tm to tm
  */
 
Index: src/interfaces/ecpg/pgtypeslib/timestamp.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c,v
retrieving revision 1.44
diff -u -3 -p -r1.44 timestamp.c
--- src/interfaces/ecpg/pgtypeslib/timestamp.c	20 May 2009 16:13:18 -0000	1.44
+++ src/interfaces/ecpg/pgtypeslib/timestamp.c	10 Jun 2009 20:42:37 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c,v 1.44 2009/05/20 16:13:18 meskes Exp $ 
+ * $PostgreSQL: pgsql/src/interfaces/ecpg/pgtypeslib/timestamp.c,v 1.44 2009/05/20 16:13:18 meskes Exp $
  */
 #include "postgres_fe.h"
 
Index: src/interfaces/ecpg/preproc/ecpg.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/ecpg.c,v
retrieving revision 1.109
diff -u -3 -p -r1.109 ecpg.c
--- src/interfaces/ecpg/preproc/ecpg.c	25 Feb 2009 13:03:07 -0000	1.109
+++ src/interfaces/ecpg/preproc/ecpg.c	10 Jun 2009 20:42:37 -0000
@@ -455,7 +455,7 @@ main(int argc, char *const argv[])
 				/* and parse the source */
 				base_yyparse();
 
-				/* 
+				/*
 				 * Check whether all cursors were indeed opened.  It
 				 * does not really make sense to declare a cursor but
 				 * not open it.
Index: src/interfaces/ecpg/preproc/output.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/output.c,v
retrieving revision 1.24
diff -u -3 -p -r1.24 output.c
--- src/interfaces/ecpg/preproc/output.c	20 Mar 2008 15:56:59 -0000	1.24
+++ src/interfaces/ecpg/preproc/output.c	10 Jun 2009 20:42:37 -0000
@@ -195,8 +195,8 @@ output_escaped_str(char *str, bool quote
 		else if (str[i] == '\\')
 		{
 			int j = i;
-			
-			/* check whether this is a continuation line 
+
+			/* check whether this is a continuation line
 			 * if it is, do not output anything because newlines are escaped anyway */
 
 			/* accept blanks after the '\' as some other compilers do too */
Index: src/interfaces/ecpg/preproc/type.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/type.c,v
retrieving revision 1.82
diff -u -3 -p -r1.82 type.c
--- src/interfaces/ecpg/preproc/type.c	23 Jan 2009 12:43:32 -0000	1.82
+++ src/interfaces/ecpg/preproc/type.c	10 Jun 2009 20:42:38 -0000
@@ -329,7 +329,7 @@ ECPGdump_a_simple(FILE *o, const char *n
 	{
 		char *variable = (char *) mm_alloc(strlen(name) + ((prefix == NULL) ? 0 : strlen(prefix)) + 4);
 		char *offset = (char *) mm_alloc(strlen(name) + strlen("sizeof(struct varchar_)") + 1 + strlen(varcharsize) + sizeof(int) * CHAR_BIT * 10 / 3);
-		char *var_name, *ptr; 
+		char *var_name, *ptr;
 
 		switch (type)
 		{
Index: src/interfaces/ecpg/preproc/type.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/ecpg/preproc/type.h,v
retrieving revision 1.50
diff -u -3 -p -r1.50 type.h
--- src/interfaces/ecpg/preproc/type.h	20 May 2008 23:17:32 -0000	1.50
+++ src/interfaces/ecpg/preproc/type.h	10 Jun 2009 20:42:38 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/interfaces/ecpg/preproc/type.h,v 1.50 2008/05/20 23:17:32 meskes Exp $ 
+ * $PostgreSQL: pgsql/src/interfaces/ecpg/preproc/type.h,v 1.50 2008/05/20 23:17:32 meskes Exp $
  */
 #ifndef _ECPG_PREPROC_TYPE_H
 #define _ECPG_PREPROC_TYPE_H
Index: src/interfaces/libpq/fe-secure.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.125
diff -u -3 -p -r1.125 fe-secure.c
--- src/interfaces/libpq/fe-secure.c	3 May 2009 17:16:58 -0000	1.125
+++ src/interfaces/libpq/fe-secure.c	10 Jun 2009 20:42:38 -0000
@@ -180,7 +180,7 @@ PQinitSSL(int do_init)
  *	Exported function to allow application to tell us it's already
  *	initialized OpenSSL and/or libcrypto.
  */
-void 
+void
 PQinitOpenSSL(int do_ssl, int do_crypto)
 {
 #ifdef USE_SSL
Index: src/interfaces/libpq/win32.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/win32.c,v
retrieving revision 1.25
diff -u -3 -p -r1.25 win32.c
--- src/interfaces/libpq/win32.c	1 Jan 2009 17:24:03 -0000	1.25
+++ src/interfaces/libpq/win32.c	10 Jun 2009 20:42:38 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/interfaces/libpq/win32.c,v 1.25 2009/01/01 17:24:03 momjian Exp $ 
+ * $PostgreSQL: pgsql/src/interfaces/libpq/win32.c,v 1.25 2009/01/01 17:24:03 momjian Exp $
  *
  *
  *	FILE
Index: src/interfaces/libpq/win32.h
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/win32.h,v
retrieving revision 1.29
diff -u -3 -p -r1.29 win32.h
--- src/interfaces/libpq/win32.h	17 May 2008 01:28:25 -0000	1.29
+++ src/interfaces/libpq/win32.h	10 Jun 2009 20:42:38 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/interfaces/libpq/win32.h,v 1.29 2008/05/17 01:28:25 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/interfaces/libpq/win32.h,v 1.29 2008/05/17 01:28:25 adunstan Exp $
  */
 #ifndef __win32_h_included
 #define __win32_h_included
Index: src/pl/plperl/plperl.c
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.149
diff -u -3 -p -r1.149 plperl.c
--- src/pl/plperl/plperl.c	6 Jun 2009 03:45:36 -0000	1.149
+++ src/pl/plperl/plperl.c	10 Jun 2009 20:42:38 -0000
@@ -273,7 +273,7 @@ _PG_init(void)
 #define SAFE_MODULE \
 	"require Safe; $Safe::VERSION"
 
-/* 
+/*
  * The temporary enabling of the caller opcode here is to work around a
  * bug in perl 5.10, which unkindly changed the way its Safe.pm works, without
  * notice. It is quite safe, as caller is informational only, and in any case
@@ -455,7 +455,7 @@ plperl_init_interp(void)
 	/* only call this the first time through, as per perlembed man page */
 	if (interp_state == INTERP_NONE)
 	{
-		char *dummy_env[1] = { NULL }; 
+		char *dummy_env[1] = { NULL };
 
 		PERL_SYS_INIT3(&nargs, (char ***) &embedding, (char ***) &dummy_env);
 	}
@@ -548,14 +548,14 @@ plperl_safe_init(void)
 		eval_pv(SAFE_OK, FALSE);
 		if (GetDatabaseEncoding() == PG_UTF8)
 		{
-			/* 
+			/*
 			 * Fill in just enough information to set up this perl
 			 * function in the safe container and call it.
 			 * For some reason not entirely clear, it prevents errors that
 			 * can arise from the regex code later trying to load
 			 * utf8 modules.
 			 */
-			plperl_proc_desc desc;			
+			plperl_proc_desc desc;
 			FunctionCallInfoData fcinfo;
 			SV *ret;
 			SV *func;
@@ -576,7 +576,7 @@ plperl_safe_init(void)
 
 			fcinfo.arg[0] = CStringGetTextDatum("a");
 			fcinfo.argnull[0] = false;
-			
+
 			/* and make the call */
 			ret = plperl_call_perl_func(&desc, &fcinfo);
 		}
Index: src/pl/plperl/spi_internal.c
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plperl/spi_internal.c,v
retrieving revision 1.9
diff -u -3 -p -r1.9 spi_internal.c
--- src/pl/plperl/spi_internal.c	17 May 2008 01:28:25 -0000	1.9
+++ src/pl/plperl/spi_internal.c	10 Jun 2009 20:42:38 -0000
@@ -1,5 +1,5 @@
 /*
- * $PostgreSQL: pgsql/src/pl/plperl/spi_internal.c,v 1.9 2008/05/17 01:28:25 adunstan Exp $ 
+ * $PostgreSQL: pgsql/src/pl/plperl/spi_internal.c,v 1.9 2008/05/17 01:28:25 adunstan Exp $
  *
  *
  * This kludge is necessary because of the conflicting
Index: src/pl/plpython/plpython.c
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plpython/plpython.c,v
retrieving revision 1.121
diff -u -3 -p -r1.121 plpython.c
--- src/pl/plpython/plpython.c	4 Jun 2009 18:33:08 -0000	1.121
+++ src/pl/plpython/plpython.c	10 Jun 2009 20:42:38 -0000
@@ -493,7 +493,7 @@ PLy_modify_tuple(PLyProcedure * proc, Py
 	PG_TRY();
 	{
 		if ((plntup = PyDict_GetItemString(pltd, "new")) == NULL)
-			ereport(ERROR, 
+			ereport(ERROR,
 					(errmsg("TD[\"new\"] deleted, cannot modify row")));
 		if (!PyDict_Check(plntup))
 			ereport(ERROR,
#36Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#35)
Re: pgindent run coming

Peter Eisentraut <peter_e@gmx.net> writes:

I think it usually does that already ...

Um, attached you will find a bunch of counterexamples.

At a quick look, I'm not sure that any of these are in code that hasn't
been edited since the 8.3 pgindent run.

regards, tom lane

#37Greg Stark
stark@enterprisedb.com
In reply to: Tom Lane (#36)
Re: pgindent run coming

On Wed, Jun 10, 2009 at 9:54 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

I think it usually does that already ...

Um, attached you will find a bunch of counterexamples.

At a quick look, I'm not sure that any of these are in code that hasn't
been edited since the 8.3 pgindent run.

On a tangent: git warns about or fixes up white-space problems like
that when you're applying a patch.

I've actually found this to be a bit of a dilemma though. For code i
want it to just go ahead and fix up anything it finds. But for
regression test expected output files I don't want it to. I don't
think you can control it per-directory though.

--
Gregory Stark
http://mit.edu/~gsstark/resume.pdf

#38Andrew Dunstan
andrew@dunslane.net
In reply to: Andrew Dunstan (#25)
Re: pgindent run coming

Andrew Dunstan wrote:

I am doing runs as requested on various platforms to extract the
typedef lists. Linux is done, Windows (mingw) is running, FBSD and
Cygwin to come.

Results in a few hours. The buildfarm will have a consolidated list.

The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get the typedefs out via objdump on FBSD would they please let us know ASAP?

Bruce, I think that's the best I can do today.

thanks

andrew

#39Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#38)
Re: pgindent run coming

Andrew Dunstan wrote:

Andrew Dunstan wrote:

I am doing runs as requested on various platforms to extract the
typedef lists. Linux is done, Windows (mingw) is running, FBSD and
Cygwin to come.

Results in a few hours. The buildfarm will have a consolidated list.

The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get the typedefs out via objdump on FBSD would they please let us know ASAP?

I will check on our Postgres shell server right away.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#40Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#39)
Re: pgindent run coming

Bruce Momjian wrote:

The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get the typedefs out via objdump on FBSD would they please let us know ASAP?

I will check on our Postgres shell server right away.

OK, so we got that working, and the consolidated list now contains FBSD
data as well.

cheers

andrew

#41Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#40)
Re: pgindent run coming

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:

I will check on our Postgres shell server right away.

OK, so we got that working, and the consolidated list now contains FBSD
data as well.

Um, let's *go* guys. RC1 wrap is scheduled for 18 hours from now.
That means it is already too late to be sure that we'll have a full
cycle of buildfarm checks on the pgindent run. Quit fooling around
and get it done.

regards, tom lane

#42Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#40)
Re: pgindent run coming

Andrew Dunstan wrote:

Bruce Momjian wrote:

The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get the typedefs out via objdump on FBSD would they please let us know ASAP?

I will check on our Postgres shell server right away.

OK, so we got that working, and the consolidated list now contains FBSD
data as well.

And where do I get the consolodated list? From?

http://www.pgbuildfarm.org/cgi-bin/typedefs.pl

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#43Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#42)
Re: pgindent run coming

Bruce Momjian wrote:

Andrew Dunstan wrote:

Bruce Momjian wrote:

The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get the typedefs out via objdump on FBSD would they please let us know ASAP?

I will check on our Postgres shell server right away.

OK, so we got that working, and the consolidated list now contains FBSD
data as well.

And where do I get the consolodated list? From?

http://www.pgbuildfarm.org/cgi-bin/typedefs.pl

yes. As previously advertised.

If you want to see the individual components, use
<http://www.pgbuildfarm.org/cgi-bin/typedefs.pl?show_list=1&gt;

cheers

andrew

#44Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#43)
Re: pgindent run coming

Andrew Dunstan wrote:

Bruce Momjian wrote:

Andrew Dunstan wrote:

Bruce Momjian wrote:

The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get the typedefs out via objdump on FBSD would they please let us know ASAP?

I will check on our Postgres shell server right away.

OK, so we got that working, and the consolidated list now contains FBSD
data as well.

And where do I get the consolodated list? From?

http://www.pgbuildfarm.org/cgi-bin/typedefs.pl

yes. As previously advertised.

If you want to see the individual components, use
<http://www.pgbuildfarm.org/cgi-bin/typedefs.pl?show_list=1&gt;

OK, pgindent run with updated list and applied to CVS HEAD. I eyeballed
the patch and it looked clean, and it tested successfully. Thanks.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#45Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#44)
Re: pgindent run coming

Bruce Momjian <bruce@momjian.us> writes:

OK, pgindent run with updated list and applied to CVS HEAD. I eyeballed
the patch and it looked clean, and it tested successfully. Thanks.

Do we have any TODO items concerning pgindent at this point? You had
mentioned wanting to research its behavior for 'struct foo var'
declarations, and I'm not too clear about whether we're happy with the
typedef collection code yet.

regards, tom lane

#46Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#45)
Re: pgindent run coming

Tom Lane wrote:

Do we have any TODO items concerning pgindent at this point? Y

Yes, we will make the buildfarm and standalone find-typedefs run from a
common pieces of code so they are always in sync.

cheers

andrew

#47Alvaro Herrera
alvherre@commandprompt.com
In reply to: Andrew Dunstan (#46)
Re: pgindent run coming

Andrew Dunstan wrote:

Tom Lane wrote:

Do we have any TODO items concerning pgindent at this point? Y

Yes, we will make the buildfarm and standalone find-typedefs run from a
common pieces of code so they are always in sync.

BTW if we had an "official" typedef list that could be used for the
length of a whole major release, we could run pgindent on a regular
basis (say fortnightly or monthly); patch submitters would just need to
run it on their own trees to avoid merge conflicts.

(Hmm, but I'm unsure how would that work with git merge etc).

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

#48Andrew Dunstan
andrew@dunslane.net
In reply to: Alvaro Herrera (#47)
Re: pgindent run coming

Alvaro Herrera wrote:

BTW if we had an "official" typedef list that could be used for the
length of a whole major release, we could run pgindent on a regular
basis (say fortnightly or monthly); patch submitters would just need to
run it on their own trees to avoid merge conflicts.

(Hmm, but I'm unsure how would that work with git merge etc).

Well, step one was finding a way to get a more comprehensive typedef
list. Now we have some sort of mechanism for doing that, we can look at
regularly pulling the list into the source, I guess. Maybe then we could
look at either regular runs or even making it a part of a commit to the
central repo, if we trust it enough. That would have the advantage of
avoiding any later merge problems.

After the release, we can play around some more.

cheers

andrew

#49Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#39)
Re: pgindent run coming

Merlin Moncure <mmoncure@gmail.com> writes:

I confirmed the aix problem on 4.3.3. Installed the patches and
updated postgres 8.4b2 removing the aix hack. Server starts fine:

$ LOG: could not bind IPv6 socket: Addr family not supported by protocol
HINT: Is another postmaster already running on port 5432? If not,
wait a few seconds and retry.
LOG: database system was shut down at 2009-06-11 13:23:32 EDT
LOG: autovacuum launcher started
LOG: database system is ready to accept connection

psql logs in. I don't know if the problem we identified this sprint
is still present...not too concered about that. pull the AIX
getaddrinfo check and go with it... no problems as best I can tell.
(out of time for this today).

OK, we'll go with that for RC1. I'll put a nonspecific note into the
docs suggesting a system update if trouble is encountered, but it would
be nice if we could add some information about exactly which fixes are
needed.

regards, tom lane

#50Merlin Moncure
mmoncure@gmail.com
In reply to: Tom Lane (#49)
Re: pgindent run coming

On Thu, Jun 11, 2009 at 2:13 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

Merlin Moncure <mmoncure@gmail.com> writes:

I confirmed the aix problem on 4.3.3. Installed the patches and
updated postgres 8.4b2 removing the aix hack.  Server starts fine:

$ LOG:  could not bind IPv6 socket: Addr family not supported by protocol
HINT:  Is another postmaster already running on port 5432? If not,
wait a few seconds and retry.
LOG:  database system was shut down at 2009-06-11 13:23:32 EDT
LOG:  autovacuum launcher started
LOG:  database system is ready to accept connection

psql logs in.  I don't know if the problem we identified this sprint
is still present...not too concered about that.  pull the AIX
getaddrinfo check and go with it... no problems as best I can tell.
(out of time for this today).

OK, we'll go with that for RC1.  I'll put a nonspecific note into the
docs suggesting a system update if trouble is encountered, but it would
be nice if we could add some information about exactly which fixes are
needed.

I just pulled the aix rollup pack...and would expect others to do the
same. It hasn't been updated since 2004-ish.

merlin

#51Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#36)
Re: pgindent run coming

On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

I think it usually does that already ...

Um, attached you will find a bunch of counterexamples.

At a quick look, I'm not sure that any of these are in code that hasn't
been edited since the 8.3 pgindent run.

So what does that mean then? Surely pgindent doesn't keep track of what has
been edited when?

#52Andrew Dunstan
andrew@dunslane.net
In reply to: Peter Eisentraut (#51)
Re: pgindent run coming

Peter Eisentraut wrote:

On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

I think it usually does that already ...

Um, attached you will find a bunch of counterexamples.

At a quick look, I'm not sure that any of these are in code that hasn't
been edited since the 8.3 pgindent run.

So what does that mean then? Surely pgindent doesn't keep track of what has
been edited when?

If the code has been edited since the last pgindent run, then pgindent
hasn't had a chance to adjust it, no?

cheers

andrew

#53Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#52)
Re: pgindent run coming

Andrew Dunstan <andrew@dunslane.net> writes:

Peter Eisentraut wrote:

On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:

At a quick look, I'm not sure that any of these are in code that hasn't
been edited since the 8.3 pgindent run.

So what does that mean then? Surely pgindent doesn't keep track of what has
been edited when?

If the code has been edited since the last pgindent run, then pgindent
hasn't had a chance to adjust it, no?

Right. Those extra spaces all represent manual editing sloppiness.

I have not done a complete check, but I looked at the first couple of
examples you cited and verified that pgindent did remove those spaces.

regards, tom lane