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

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.

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

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

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.

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

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

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)

[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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

[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

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

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

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,

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.

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

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:

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

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

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

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 logic

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

[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 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);

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

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 pgindent

[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 behavior we could do without

On Thu, Jan 30, 2014 at 11:44:31PM -0500, Tom Lane wrote: Bruce Momjian br...@momjian.us 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

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.

[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 wishlist item

Andrew Dunstan and...@dunslane.net 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

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

On Fri, Jan 31, 2014 at 12:44:22PM -0500, Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

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

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 orders

Re: [HACKERS] pgindent behavior we could do without

Bruce Momjian br...@momjian.us 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

Re: [HACKERS] pgindent behavior we could do without

On Thu, Jan 30, 2014 at 01:46:34PM -0500, Tom Lane wrote: Bruce Momjian br...@momjian.us 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

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 br...@momjian.us 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

Re: [HACKERS] pgindent behavior we could do without

Bruce Momjian br...@momjian.us 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

Re: [HACKERS] pgindent behavior we could do without

On 07/18/2013 11:30 PM, Tom Lane wrote: Noah Misch n...@leadboat.com 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

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 orders

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 orders

Re: [HACKERS] pgindent behavior we could do without

Noah Misch n...@leadboat.com 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

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

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 stdlib.h to

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 stdlib.h to the parse.c file (as included in the

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

On Wed, Feb 8, 2012 at 8:13 AM, Magnus Hagander mag...@hagander.net 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

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 stdlib.h to the parse.c file (as included in the pg_bsd_indent-1.1.tar.gz file at ftp://ftp.postgresql.org/pub/dev ).  

[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 stdlib.h to the parse.c file (as included in the pg_bsd_indent-1.1.tar.gz file

Re: [HACKERS] pgindent README correction

On Mon, Jan 9, 2012 at 12:31 PM, Kevin Grittner kevin.gritt...@wicourts.gov 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

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: Bruce Momjian br...@momjian.us 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

[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 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 value of

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 *

Re: [HACKERS] pgindent messing up translator: comments

Alvaro Herrera alvhe...@alvh.no-ip.org 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 */

Re: [HACKERS] pgindent messing up translator: comments

Excerpts from Tom Lane's message of lun sep 05 16:43:32 -0300 2011: Alvaro Herrera alvhe...@alvh.no-ip.org 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,

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

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

Re: [HACKERS] pgindent weirdness

Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] pgindent weirdnessf

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

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

Bruce Momjian br...@momjian.us 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: Bruce Momjian br...@momjian.us 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

On 04/20/2011 11:43 AM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net 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

Re: [HACKERS] pgindent weirdness

Andrew Dunstan and...@dunslane.net 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

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

Re: [HACKERS] pgindent weirdness

On 04/20/2011 12:29 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net 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

Re: [HACKERS] pgindent weirdness

On Wed, Apr 20, 2011 at 12:38 PM, Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] pgindent weirdness

Aidan Van Dyk ai...@highrise.ca 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

Re: [HACKERS] pgindent weirdness

On Wed, Apr 20, 2011 at 11:15 AM, Andrew Dunstan and...@dunslane.net 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

Robert Haas wrote: On Wed, Apr 20, 2011 at 11:15 AM, Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] pgindent weirdness

On 04/20/2011 01:12 PM, Robert Haas wrote: On Wed, Apr 20, 2011 at 11:15 AM, Andrew Dunstanand...@dunslane.net 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

Re: [HACKERS] pgindent weirdnessf

On Wed, Apr 20, 2011 at 12:33 PM, Andrew Dunstan and...@dunslane.net 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

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

Re: [HACKERS] pgindent weirdnessf

Robert Haas wrote: On Wed, Apr 20, 2011 at 12:33 PM, Andrew Dunstan and...@dunslane.net 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

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 weirdness

On 04/20/2011 01:10 PM, Tom Lane wrote: Aidan Van Dykai...@highrise.ca 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

Re: [HACKERS] pgindent weirdness

Andrew Dunstan and...@dunslane.net 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.

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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

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

Re: [HACKERS] pgindent weirdness

Andrew Dunstan and...@dunslane.net 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

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: Andrew Dunstan and...@dunslane.net 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,

Re: [HACKERS] pgindent weirdness

On 04/20/2011 05:29 PM, Tom Lane wrote: Andrew Dunstanand...@dunslane.net 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

[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

Re: [HACKERS] pgindent

Bruce Momjian wrote: Robert Haas wrote: On Fri, Apr 8, 2011 at 11:21 PM, Andrew Dunstan and...@dunslane.net wrote: We've got more work to do before that works, so I have committed what we have. Some symbols have disappeared, some because of code changes and some probably because Cygwin

  1   2   3   >