Re: [HACKERS] pgindent fixups

Robert Haas writes: > So I really would like to get a pgindent run done. Any objections to > doing it sometime RSN? It is of course possible that it might make > something that we want to revert later harder to revert, but I think > we should just accept that risk and move forward. Now that we

Re: [HACKERS] pgindent fixups

On Tue, May 3, 2016 at 11:31 AM, Robert Haas wrote: > On Tue, May 3, 2016 at 11:23 AM, Tom Lane wrote: >> Robert Haas writes: >>> OK, I committed this. Barring objections, I'll go ahead and pgindent >>> the whole tree tomorrow. If we're going to revert anything big then >>> we might want to ho

Re: [HACKERS] pgindent fixups

Robert Haas writes: > On Tue, May 3, 2016 at 11:23 AM, Tom Lane wrote: >> Well, there are at least two patchsets we're actively discussing >> reverting, so I think this should wait till those decisions are resolved. > OK, but that may well mean we don't get this done before beta1, which > I thin

Re: [HACKERS] pgindent fixups

On Tue, May 3, 2016 at 11:23 AM, Tom Lane wrote: > Robert Haas writes: >> OK, I committed this. Barring objections, I'll go ahead and pgindent >> the whole tree tomorrow. If we're going to revert anything big then >> we might want to hold off, but otherwise I think its better to get >> this don

Re: [HACKERS] pgindent fixups

Robert Haas writes: > OK, I committed this. Barring objections, I'll go ahead and pgindent > the whole tree tomorrow. If we're going to revert anything big then > we might want to hold off, but otherwise I think its better to get > this done sooner rather than later. Well, there are at least tw

Re: [HACKERS] pgindent fixups

On Tue, May 3, 2016 at 9:40 AM, Tom Lane wrote: > Robert Haas writes: >> 1. Is pgindent supposed to touch DATA() lines? Because it does. > > It always has. > >> 2. CustomPathMethods is not in the buildfarm's typedefs.list. Why not? > > Probably because there are no variables, parameters, or fie

Re: [HACKERS] pgindent fixups

Robert Haas writes: > 1. Is pgindent supposed to touch DATA() lines? Because it does. It always has. > 2. CustomPathMethods is not in the buildfarm's typedefs.list. Why not? Probably because there are no variables, parameters, or fields declared with that typedef, so it doesn't get into the d

Re: [HACKERS] pgindent fixups

On 05/02/2016 10:56 PM, Robert Haas wrote: I spent some time going through the output of a trial pgindent run today. Some questions/problems: 1. Is pgindent supposed to touch DATA() lines? Because it does. Apart from being detabbed/entabbed, no. pgindent protects (or tries to protect) DA

[HACKERS] pgindent fixups

I spent some time going through the output of a trial pgindent run today. Some questions/problems: 1. Is pgindent supposed to touch DATA() lines? Because it does. 2. CustomPathMethods is not in the buildfarm's typedefs.list. Why not? I'm attaching a patch that fixes up a few other problems th

Re: [HACKERS] pgindent

Robert Haas writes: > I compared the result of running pgindent with the typedefs.list file > as updated by me manually with the result of running pgindent using > the buildfarm list and ... the buildfarm list is better. Shows what I > know. Should we go ahead and commit the current version of t

Re: [HACKERS] pgindent

On Thu, Apr 28, 2016 at 7:39 AM, Bruce Momjian wrote: > On Wed, Apr 27, 2016 at 11:38:57PM -0400, Robert Haas wrote: >> > On what grounds do you claim the buildfarm result is unstable? >> > I've been using that for a long time and it works fine. Moreover, >> > ignoring that data is a bad idea bec

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 11:38:57PM -0400, Robert Haas wrote: > > On what grounds do you claim the buildfarm result is unstable? > > I've been using that for a long time and it works fine. Moreover, > > ignoring that data is a bad idea because it reflects platform-specific > > variations in the set

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 6:10 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Apr 27, 2016 at 2:23 PM, Tom Lane wrote: >>> Um, we normally take the buildfarm's list of typedefs, not anything >>> manually created. > >> Well, we can still do that, but I don't see much advantage in it. It >> j

Re: [HACKERS] pgindent

Robert Haas writes: > On Wed, Apr 27, 2016 at 2:23 PM, Tom Lane wrote: >> Um, we normally take the buildfarm's list of typedefs, not anything >> manually created. > Well, we can still do that, but I don't see much advantage in it. It > just churns the file to the extent that manual review of th

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 05:01:14PM -0400, Bruce Momjian wrote: > On Wed, Apr 27, 2016 at 02:54:35PM -0400, Robert Haas wrote: > > On Wed, Apr 27, 2016 at 2:23 PM, Tom Lane wrote: > > > Robert Haas writes: > > >> I think it's about time for us to run pgindent. I did a trial run > > >> today of pg

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 02:54:35PM -0400, Robert Haas wrote: > On Wed, Apr 27, 2016 at 2:23 PM, Tom Lane wrote: > > Robert Haas writes: > >> I think it's about time for us to run pgindent. I did a trial run > >> today of pgindent today and came up with the attached patch for > >> typedefs.list,

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 2:23 PM, Tom Lane wrote: > Robert Haas writes: >> I think it's about time for us to run pgindent. I did a trial run >> today of pgindent today and came up with the attached patch for >> typedefs.list, which I'd like to commit more or less immediately, >> barring objection

Re: [HACKERS] pgindent

Robert Haas writes: > I think it's about time for us to run pgindent. I did a trial run > today of pgindent today and came up with the attached patch for > typedefs.list, which I'd like to commit more or less immediately, > barring objections. Um, we normally take the buildfarm's list of typedef

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 11:57 AM, Bruce Momjian wrote: > On Wed, Apr 27, 2016 at 11:51:42AM -0400, Robert Haas wrote: >> >> It mostly just adds new typedefs that have >> >> appeared over the last year, but it also realphabetizes the file - >> >> some things that were added incrementally seem to ha

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 11:51:42AM -0400, Robert Haas wrote: > >> It mostly just adds new typedefs that have > >> appeared over the last year, but it also realphabetizes the file - > >> some things that were added incrementally seem to have ended up in > >> what is, at least according to what sort

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 10:57 AM, Bruce Momjian wrote: > Agreed. Sounds like a good plan --- a better plan than I have used in > the past. Thinking about this a bit more, what I am inclined to do is: 1. Run pgindent. 2. Read the diff and revert any changes that look icky. 3. Commit the rest.

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 11:45 AM, Andres Freund wrote: > Yes, that makes sense. That way other can easily look at "their" code, > to see whether it can be made more pgindent resistant ;) Right. >> It mostly just adds new typedefs that have >> appeared over the last year, but it also realphabetiz

Re: [HACKERS] pgindent

On 2016-04-27 10:51:55 -0400, Robert Haas wrote: > I think it's about time for us to run pgindent. Sounds reasonable. > I did a trial run > today of pgindent today and came up with the attached patch for > typedefs.list, which I'd like to commit more or less immediately, > barring objections. Ye

[HACKERS] pgindent

I think it's about time for us to run pgindent. I did a trial run today of pgindent today and came up with the attached patch for typedefs.list, which I'd like to commit more or less immediately, barring objections. It mostly just adds new typedefs that have appeared over the last year, but it al

Re: [HACKERS] pgindent

On Wed, Apr 27, 2016 at 10:51:55AM -0400, Robert Haas wrote: > I think it's about time for us to run pgindent. I did a trial run > today of pgindent today and came up with the attached patch for > typedefs.list, which I'd like to commit more or less immediately, > barring objections. It mostly ju

Re: [HACKERS] pgindent-polluted commits

On Sat, Jan 16, 2016 at 09:57:45AM +, Simon Riggs wrote: > On 16 January 2016 at 02:10, Noah Misch wrote: > > On Wed, Jan 13, 2016 at 12:13:11PM -0500, Tom Lane wrote: > > > Basically this is trading off convenience of the committer (all of the > > > alternatives Noah mentions are somewhat ann

Re: [HACKERS] pgindent-polluted commits

On 16 January 2016 at 02:10, Noah Misch wrote: > On Wed, Jan 13, 2016 at 12:13:11PM -0500, Tom Lane wrote: > > Simon Riggs writes: > > > On 13 January 2016 at 14:48, Noah Misch wrote: > > >> I've noticed commits, from a few of you, carrying pgindent changes to > lines > > >> the patch would not

Re: [HACKERS] pgindent-polluted commits

On Wed, Jan 13, 2016 at 12:13:11PM -0500, Tom Lane wrote: > Simon Riggs writes: > > On 13 January 2016 at 14:48, Noah Misch wrote: > >> I've noticed commits, from a few of you, carrying pgindent changes to lines > >> the patch would not otherwise change. > > > Could we review again why this matt

Re: [HACKERS] pgindent-polluted commits

On Thu, Jan 14, 2016 at 11:25 AM, Andrew Dunstan wrote: > I do think it makes life easier when going through the git history if > semantic changes are separated from formatting changes. I agree. And I agree with Mark Dilger's point, too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] pgindent-polluted commits

On 01/13/2016 12:13 PM, Tom Lane wrote: Simon Riggs writes: On 13 January 2016 at 14:48, Noah Misch wrote: I've noticed commits, from a few of you, carrying pgindent changes to lines the patch would not otherwise change. Could we review again why this matters? Basically this is trading of

Re: [HACKERS] pgindent-polluted commits

On Wed, Jan 13, 2016 at 9:13 AM, Tom Lane wrote: > I'm willing to go with the "separate commit to reindent individual files" > approach if there's a consensus that that makes for a cleaner git history. > But I'm not 100% convinced it matters. I recently changed the configuration of my text editor

Re: [HACKERS] pgindent-polluted commits

> On Jan 13, 2016, at 9:13 AM, Tom Lane wrote: > > Simon Riggs writes: >> On 13 January 2016 at 14:48, Noah Misch wrote: >>> I've noticed commits, from a few of you, carrying pgindent changes to lines >>> the patch would not otherwise change. > >> Could we review again why this matters? > >

Re: [HACKERS] pgindent-polluted commits

Simon Riggs writes: > On 13 January 2016 at 14:48, Noah Misch wrote: >> I've noticed commits, from a few of you, carrying pgindent changes to lines >> the patch would not otherwise change. > Could we review again why this matters? Basically this is trading off convenience of the committer (all

Re: [HACKERS] pgindent-polluted commits

On 13 January 2016 at 14:48, Noah Misch wrote: > I've noticed commits, from a few of you, carrying pgindent changes to lines > the patch would not otherwise change. Could we review again why this matters? -- Simon Riggshttp://www.2ndQuadrant.com/

[HACKERS] pgindent-polluted commits

I've noticed commits, from a few of you, carrying pgindent changes to lines the patch would not otherwise change. (That is to say, the next pgindent run would have made the same changes anyway.) From https://wiki.postgresql.org/wiki/Submitting_a_Patch#Reasons_your_patch_might_be_returned: The

Re: [HACKERS] pgindent vs emacs

On 05/29/2015 01:49 PM, Andres Freund wrote: On 2015-05-29 13:37:40 -0400, Andrew Dunstan wrote: One of the annoying inconsistencies between emacs and pgindent is that emacs refuses to offset a block following a case label, while pgindent does. Is there anything we can do to induce emacs to do

Re: [HACKERS] pgindent vs emacs

On 2015-05-29 13:37:40 -0400, Andrew Dunstan wrote: > One of the annoying inconsistencies between emacs and pgindent is that emacs > refuses to offset a block following a case label, while pgindent does. Is > there anything we can do to induce emacs to do what pgindent does? Are you using the logi

[HACKERS] pgindent vs emacs

One of the annoying inconsistencies between emacs and pgindent is that emacs refuses to offset a block following a case label, while pgindent does. Is there anything we can do to induce emacs to do what pgindent does? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postg

Re: [HACKERS] pgindent weirdness

On Thu, Jul 10, 2014 at 12:02:50PM -0400, Robert Haas wrote: > In contrib/test_shm_mq/test.c, the 9.4 pgindent run > (0a7832005792fa6dad171f9cadb8d587fe0dd800) did this: > > -PG_MODULE_MAGIC; > -PG_FUNCTION_INFO_V1(test_shm_mq); > +PG_MODULE_MAGIC; PG_FUNCTION_INFO_V1(test_shm_mq); > PG_FUNCTION_

[HACKERS] pgindent weirdness

In contrib/test_shm_mq/test.c, the 9.4 pgindent run (0a7832005792fa6dad171f9cadb8d587fe0dd800) did this: -PG_MODULE_MAGIC; -PG_FUNCTION_INFO_V1(test_shm_mq); +PG_MODULE_MAGIC; PG_FUNCTION_INFO_V1(test_shm_mq); PG_FUNCTION_INFO_V1(test_shm_mq_pipelined); This is obviously not an improvement. Is

Re: [HACKERS] pgindent run

On Tue, May 6, 2014 at 08:55:07AM -0400, Bruce Momjian wrote: > On Sat, May 3, 2014 at 02:20:27PM -0400, Bruce Momjian wrote: > > I am planning to run pgindent in a few days to prepare for beta. Does > > anyone have major patches that you are planning to apply soon? If so, I > > can delay pgind

Re: [HACKERS] pgindent run

On Sat, May 3, 2014 at 02:20:27PM -0400, Bruce Momjian wrote: > I am planning to run pgindent in a few days to prepare for beta. Does > anyone have major patches that you are planning to apply soon? If so, I > can delay pgindent until you are done. > > This run will also have a tabs-in-commen

[HACKERS] pgindent run

I am planning to run pgindent in a few days to prepare for beta. Does anyone have major patches that you are planning to apply soon? If so, I can delay pgindent until you are done. This run will also have a tabs-in-comments removal phase which will also be run on supported back branches. --

Re: [HACKERS] pgindent wishlist item

On Fri, Jan 31, 2014 at 07:15:05PM +0100, Andres Freund wrote: > On 2014-01-31 12:29:52 -0500, Andrew Dunstan wrote: > > While Bruce is working on pgindent > > If it's christmas, let me wish for a not completly broken formatting of > function typedefs. E.g. > typedef ForeignScan *(*GetForeignPlan_

Re: [HACKERS] pgindent wishlist item

On Fri, Jan 31, 2014 at 12:44:22PM -0500, Tom Lane wrote: > Andrew Dunstan writes: > > While Bruce is working on pgindent, let me register a small wishlist > > item. It would be quite useful to be able to supply extra typedefs on > > the command line to supplement a typedefs file downloaded from

Re: [HACKERS] pgindent wishlist item

On 2014-01-31 12:29:52 -0500, Andrew Dunstan wrote: > While Bruce is working on pgindent If it's christmas, let me wish for a not completly broken formatting of function typedefs. E.g. typedef ForeignScan *(*GetForeignPlan_function) (PlannerInfo *root,

Re: [HACKERS] pgindent wishlist item

Andrew Dunstan writes: > While Bruce is working on pgindent, let me register a small wishlist > item. It would be quite useful to be able to supply extra typedefs on > the command line to supplement a typedefs file downloaded from the > buildfarm or constructed however. A concrete example: in t

[HACKERS] pgindent wishlist item

While Bruce is working on pgindent, let me register a small wishlist item. It would be quite useful to be able to supply extra typedefs on the command line to supplement a typedefs file downloaded from the buildfarm or constructed however. A concrete example: in the code I have been recently

Re: [HACKERS] pgindent behavior we could do without

On Fri, Jan 31, 2014 at 11:18:17AM -0500, Bruce Momjian wrote: > Yes, it is a shame pgindent has removed many proper empty lines in the > past and there is no way to re-add them without causing backpatching > problems. FYI, the original BSD indent code that added the blank lines kind of made sense

Re: [HACKERS] pgindent behavior we could do without

On Thu, Jan 30, 2014 at 11:44:31PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > OK, seven hours later, I have fixed pg_bsd_indent to no longer insert > > blank lines above #elif/#else/#endif, and therefore removed the special > > case code from pgindent. > > > You will need to download vers

Re: [HACKERS] pgindent behavior we could do without

Bruce Momjian writes: > OK, seven hours later, I have fixed pg_bsd_indent to no longer insert > blank lines above #elif/#else/#endif, and therefore removed the special > case code from pgindent. > You will need to download version 1.3 of pg_bsd_indent for this to work, > and pgindent will complai

Re: [HACKERS] pgindent behavior we could do without

On Thu, Jan 30, 2014 at 01:52:55PM -0500, Bruce Momjian wrote: > On Thu, Jan 30, 2014 at 01:46:34PM -0500, Tom Lane wrote: > > Bruce Momjian writes: > > > On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote: > > >> I assert that we should simply remove both of these bits of code, as > > >> ju

Re: [HACKERS] pgindent behavior we could do without

On Thu, Jan 30, 2014 at 01:46:34PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote: > >> I assert that we should simply remove both of these bits of code, as > >> just about every committer on the project is smarter about when to use > >>

Re: [HACKERS] pgindent behavior we could do without

Bruce Momjian writes: > On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote: >> I assert that we should simply remove both of these bits of code, as >> just about every committer on the project is smarter about when to use >> vertical whitespace than this program is. > OK, I have developed t

Re: [HACKERS] pgindent behavior we could do without

On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote: > It's always annoyed me that pgindent insists on adjusting vertical > whitespace around #else and related commands. This has, for example, > rendered src/include/storage/barrier.h nigh illegible: you get things > like > > /* > * lwsync o

Re: [HACKERS] pgindent behavior we could do without

On 07/18/2013 11:30 PM, Tom Lane wrote: Noah Misch writes: On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote: It's always annoyed me that pgindent insists on adjusting vertical whitespace around #else and related commands. This has, for example, rendered src/include/storage/barrier.h

Re: [HACKERS] pgindent behavior we could do without

Noah Misch writes: > On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote: >> It's always annoyed me that pgindent insists on adjusting vertical >> whitespace around #else and related commands. This has, for example, >> rendered src/include/storage/barrier.h nigh illegible: you get things >>

Re: [HACKERS] pgindent behavior we could do without

On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote: > It's always annoyed me that pgindent insists on adjusting vertical > whitespace around #else and related commands. This has, for example, > rendered src/include/storage/barrier.h nigh illegible: you get things > like > > /* > * lwsync o

Re: [HACKERS] pgindent behavior we could do without

On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote: > It's always annoyed me that pgindent insists on adjusting vertical > whitespace around #else and related commands. This has, for example, > rendered src/include/storage/barrier.h nigh illegible: you get things > like > > /* > * lwsync o

[HACKERS] pgindent behavior we could do without

It's always annoyed me that pgindent insists on adjusting vertical whitespace around #else and related commands. This has, for example, rendered src/include/storage/barrier.h nigh illegible: you get things like /* * lwsync orders loads with respect to each other, and similarly with stores. * Bu

Re: [HACKERS] pgindent README correction

On Mon, Jan 9, 2012 at 11:31:02AM -0600, Kevin Grittner wrote: > I found that I needed to adjust the command given in the README file > for pgindent. Trivial patch attached. > > The one other issue I ran into in following the latest pgindent > instructions was that I had to add #include to the

Re: [pgsql-www] [HACKERS] pgindent README correction

On Wed, Feb 8, 2012 at 8:13 AM, Magnus Hagander wrote: > On Wednesday, February 8, 2012, Bruce Momjian wrote: >> >> On Mon, Jan 09, 2012 at 01:32:49PM -0500, Robert Haas wrote: >> > > The one other issue I ran into in following the latest pgindent >> > > instructions was that I had to add #include

Re: [HACKERS] pgindent README correction

On Wednesday, February 8, 2012, Bruce Momjian wrote: > On Mon, Jan 09, 2012 at 01:32:49PM -0500, Robert Haas wrote: > > > The one other issue I ran into in following the latest pgindent > > > instructions was that I had to add #include to the > > > parse.c file (as included in the pg_bsd_indent-1

Re: [HACKERS] pgindent README correction

On Mon, Jan 09, 2012 at 01:32:49PM -0500, Robert Haas wrote: > > The one other issue I ran into in following the latest pgindent > > instructions was that I had to add #include to the > > parse.c file (as included in the pg_bsd_indent-1.1.tar.gz file at > > ftp://ftp.postgresql.org/pub/dev ).  Wit

Re: [HACKERS] pgindent README correction

On Mon, Jan 9, 2012 at 12:31 PM, Kevin Grittner wrote: > I found that I needed to adjust the command given in the README file > for pgindent.  Trivial patch attached. Committed. > The one other issue I ran into in following the latest pgindent > instructions was that I had to add #include to th

[HACKERS] pgindent README correction

I found that I needed to adjust the command given in the README file for pgindent. Trivial patch attached. The one other issue I ran into in following the latest pgindent instructions was that I had to add #include to the parse.c file (as included in the pg_bsd_indent-1.1.tar.gz file at ftp://f

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Now having said that, there seems to be a pgindent bug here too, in that > >> it's throwing a space into > >> > >> Buffer > >> RelationGetBufferForTuple(Relation relation, Size len, > >> Buffer otherBuffer, int options, > >> struct

Re: [HACKERS] pgindent messing up "translator: " comments

Excerpts from Tom Lane's message of lun sep 05 16:43:32 -0300 2011: > Alvaro Herrera writes: > > I think the proper fix would be to use the /* trick, such as in > > postmaster.c: > > > /*-- > > translator: %s is a noun phrase describing a child process, such > > as > >

Re: [HACKERS] pgindent messing up "translator: " comments

Alvaro Herrera writes: > I think the proper fix would be to use the /* trick, such as in > postmaster.c: > /*-- > translator: %s is a noun phrase describing a child process, > such as > "server process" */ > (err

Re: [HACKERS] pgindent messing up "translator: " comments

Excerpts from Alvaro Herrera's message of lun sep 05 16:21:38 -0300 2011: > I just noticed that this comment got reindented by pgindent > (xlog.c, line 3226 in REL9_1_STABLE): > /* > * translator: First %s represents a recovery.conf parameter name like > * "recovery_end_co

Re: [HACKERS] pgindent messing up "translator: " comments

Alvaro Herrera wrote: > I just noticed that this comment got reindented by pgindent > (xlog.c, line 3226 in REL9_1_STABLE): > /* >* translator: First %s represents a recovery.conf parameter > name like >* "recovery_end_command", and the 2nd is the valu

[HACKERS] pgindent messing up "translator: " comments

I just noticed that this comment got reindented by pgindent (xlog.c, line 3226 in REL9_1_STABLE): /* * translator: First %s represents a recovery.conf parameter name like * "recovery_end_command", and the 2nd is the value of that parameter.

Re: [HACKERS] pgindent weirdness

On 04/20/2011 05:29 PM, Tom Lane wrote: Andrew Dunstan writes: On 04/20/2011 04:28 PM, Bruce Momjian wrote: So the list of possible additions Andrew supplied are cases where we never reference those typedefs --- seems like a cleanup opportunity. I think the best cleanup idea is Aidan's, nam

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: > Andrew Dunstan writes: > > On 04/20/2011 04:28 PM, Bruce Momjian wrote: > >> So the list of possible additions Andrew supplied are cases where we > >> never reference those typedefs --- seems like a cleanup opportunity. > > > I think the best cleanup idea is Aidan's, namely is w

Re: [HACKERS] pgindent weirdness

Andrew Dunstan writes: > On 04/20/2011 04:28 PM, Bruce Momjian wrote: >> So the list of possible additions Andrew supplied are cases where we >> never reference those typedefs --- seems like a cleanup opportunity. > I think the best cleanup idea is Aidan's, namely is we have declared > "typdef s

Re: [HACKERS] pgindent weirdness

On 04/20/2011 04:28 PM, Bruce Momjian wrote: So the list of possible additions Andrew supplied are cases where we never reference those typedefs --- seems like a cleanup opportunity. I think the best cleanup idea is Aidan's, namely is we have declared "typdef struct foo { ... } foo;" we sho

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: > Andrew Dunstan writes: > > On 04/20/2011 01:16 PM, Bruce Momjian wrote: > >>> This implies to me that we changed something about how we handle this > >>> since we did the 9.0 runs, but I don't know what it was. Should I? > > >> I think Andrew also supplied the typedef list for

Re: [HACKERS] pgindent weirdness

Andrew Dunstan writes: > On 04/20/2011 01:16 PM, Bruce Momjian wrote: >>> This implies to me that we changed something about how we handle this >>> since we did the 9.0 runs, but I don't know what it was. Should I? >> I think Andrew also supplied the typedef list for the 9.0 run. > Yes. But in

Re: [HACKERS] pgindent weirdness

On 04/20/2011 01:10 PM, Tom Lane wrote: Aidan Van Dyk writes: Since the general form seems to be to declare things as: typedef struct foo { ... } foo; Is there any reason why we see any struct foo in the sources other than in the typedef line? It gives an escape hatch in case you need a

Re: [HACKERS] pgindent weirdnessf

On 04/20/2011 01:59 PM, Bruce Momjian wrote: I do, agree, though, it would be nice to find out what changed that caused this. I am 100% certain that it's the tools that have changed. I bet if I were to hunt in my pile of old DVDs and find installation media for Fedora 6 or thereabouts and

Re: [HACKERS] pgindent weirdnessf

Robert Haas wrote: > On Wed, Apr 20, 2011 at 12:33 PM, Andrew Dunstan wrote: > > You can contribute to the list by running a buildfarm animal on your machine > > and running its find_typedefs occasionally. This is not just about me. I > > have asked on numerous occasions for other people to contri

Re: [HACKERS] pgindent weirdness

On 04/20/2011 01:16 PM, Bruce Momjian wrote: This implies to me that we changed something about how we handle this since we did the 9.0 runs, but I don't know what it was. Should I? I think Andrew also supplied the typedef list for the 9.0 run. Yes. But in November, the server where all m

Re: [HACKERS] pgindent weirdnessf

On Wed, Apr 20, 2011 at 12:33 PM, Andrew Dunstan wrote: > You can contribute to the list by running a buildfarm animal on your machine > and running its find_typedefs occasionally. This is not just about me. I > have asked on numerous occasions for other people to contribute, and the > response ha

Re: [HACKERS] pgindent weirdness

On 04/20/2011 01:12 PM, Robert Haas wrote: On Wed, Apr 20, 2011 at 11:15 AM, Andrew Dunstan wrote: I did carefully warn you about the need to check the effects of the changes when I committed the new list. It looks like quite a few of the deletions come into this category, for example just l

Re: [HACKERS] pgindent weirdness

Robert Haas wrote: > On Wed, Apr 20, 2011 at 11:15 AM, Andrew Dunstan wrote: > > I did carefully warn you about the need to check the effects of the changes > > when I committed the new list. > > > > It looks like quite a few of the deletions come into this category, for > > example just looking a

Re: [HACKERS] pgindent weirdness

On Wed, Apr 20, 2011 at 11:15 AM, Andrew Dunstan wrote: > I did carefully warn you about the need to check the effects of the changes > when I committed the new list. > > It looks like quite a few of the deletions come into this category, for > example just looking at the diff here >

Re: [HACKERS] pgindent weirdness

Aidan Van Dyk writes: > Since the general form seems to be to declare things as: >typedef struct foo { ... } foo; > Is there any reason why we see any struct foo in the sources other > than in the typedef line? It gives an escape hatch in case you need a forward reference to the struct, ie y

Re: [HACKERS] pgindent weirdness

On Wed, Apr 20, 2011 at 12:38 PM, Andrew Dunstan wrote: >> So in the case at hand, we actually *need* to remove the "struct" from >> RelationGetBufferForTuple's declaration, so that BulkInsertStateData >> gets used as a typedef name in that way. Since the general form seems to be to declare thin

Re: [HACKERS] pgindent weirdness

On 04/20/2011 12:29 PM, Tom Lane wrote: Andrew Dunstan writes: But in any case, *none* of the individual files knows about BulkInsertStateData as a typedef: ... And the reason is actually fairly obvious on closer inspection. The only place we actually use the BulkInsertStateData typedef (as o

Re: [HACKERS] pgindent weirdnessf

On 04/20/2011 11:48 AM, Bruce Momjian wrote: I assume you are using -g, right? Of course I did. I wouldn't have any symbols at all if I didn't. The BulkInsertStateData typedef looks pretty normal: typedef struct BulkInsertStateData { BufferAccessStrategy strate

Re: [HACKERS] pgindent weirdness

Andrew Dunstan writes: > But in any case, *none* of the individual files knows about > BulkInsertStateData as a typedef: > ... > And the reason is actually fairly obvious on closer inspection. The only > place we actually use the BulkInsertStateData typedef (as opposed to the > struct declarati

Re: [HACKERS] pgindent weirdness

On 04/20/2011 11:43 AM, Tom Lane wrote: Andrew Dunstan writes: On 04/20/2011 05:48 AM, Bruce Momjian wrote: BulkInsertStateData is not listed in the typedef list supplied by Andrew; see src/tools/pgindent/typedefs.list. CC'ing him. This might be because the typdef is listed in two files:

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Now having said that, there seems to be a pgindent bug here too, in that > >> it's throwing a space into > >> > >> Buffer > >> RelationGetBufferForTuple(Relation relation, Size len, > >> Buffer otherBuffer, int options, > >> struct

Re: [HACKERS] pgindent weirdness

Bruce Momjian writes: > Tom Lane wrote: >> Now having said that, there seems to be a pgindent bug here too, in that >> it's throwing a space into >> >> Buffer >> RelationGetBufferForTuple(Relation relation, Size len, >> Buffer otherBuffer, int options, >> struct BulkInsertStateData * bistate) >>

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: > Andrew Dunstan writes: > > On 04/20/2011 05:48 AM, Bruce Momjian wrote: > >> BulkInsertStateData is not listed in the typedef list supplied by > >> Andrew; see src/tools/pgindent/typedefs.list. CC'ing him. This might > >> be because the typdef is listed in two files: > > > It'

Re: [HACKERS] pgindent weirdnessf

Andrew Dunstan wrote: > It's tagged as a structure type by objdump, but not as a typedef: > > <1><40055>: Abbrev Number: 4 (DW_TAG_typedef) > <40056> DW_AT_name: (indirect string, offset: 0x6bf6): > BulkInsertState > <4005a> DW_AT_decl_file : 30 > <4005b> DW_AT_

Re: [HACKERS] pgindent weirdness

Andrew Dunstan writes: > On 04/20/2011 05:48 AM, Bruce Momjian wrote: >> BulkInsertStateData is not listed in the typedef list supplied by >> Andrew; see src/tools/pgindent/typedefs.list. CC'ing him. This might >> be because the typdef is listed in two files: > It's tagged as a structure type b

Re: [HACKERS] pgindent weirdness

On 04/20/2011 05:48 AM, Bruce Momjian wrote: Robert Haas wrote: pgindent seems to have muffed it when it comes to BulkInsertStateData: diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c index 2849992..72a69e5 100644 --- a/src/backend/access/heap/hio.c +++ b/src/backend

Re: [HACKERS] pgindent weirdness

Robert Haas wrote: > pgindent seems to have muffed it when it comes to BulkInsertStateData: > > diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c > index 2849992..72a69e5 100644 > --- a/src/backend/access/heap/hio.c > +++ b/src/backend/access/heap/hio.c > @@ -150,7 +150,7

[HACKERS] pgindent weirdness

pgindent seems to have muffed it when it comes to BulkInsertStateData: diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c index 2849992..72a69e5 100644 --- a/src/backend/access/heap/hio.c +++ b/src/backend/access/heap/hio.c @@ -150,7 +150,7 @@ ReadBufferBI(Relation relation

  1   2   3   4   >