On Sun, Apr 10, 2011 at 4:42 PM, Bruce Momjian br...@momjian.us wrote:
27 hours later, done. I ran all the tests outlined in the pgindent
README.
What's with things like:
-void _PG_init(void);
+void _PG_init(void);
- Datum diff = DirectFunctionCall2(date_mi,
+ Datum diff =
And this doesn't seem helpful:
/* Format options */
/* oids option is not supported */
- { format, ForeignTableRelationId },
- { header, ForeignTableRelationId },
- { delimiter, ForeignTableRelationId },
- { quote, ForeignTableRelationId },
- {
On Sun, Apr 10, 2011 at 11:55 AM, Greg Stark gsst...@mit.edu wrote:
On Sun, Apr 10, 2011 at 4:42 PM, Bruce Momjian br...@momjian.us wrote:
27 hours later, done. I ran all the tests outlined in the pgindent
README.
What's with things like:
-void _PG_init(void);
+void
Robert Haas robertmh...@gmail.com writes:
On Sun, Apr 10, 2011 at 11:55 AM, Greg Stark gsst...@mit.edu wrote:
Note that in the last one someone carefully made the variable names
line up and pgindent is changing the spacing to an arbitrary amount.
Well, it's the same arbitrary amount that we
Robert Haas wrote:
On Sun, Apr 10, 2011 at 11:55 AM, Greg Stark gsst...@mit.edu wrote:
On Sun, Apr 10, 2011 at 4:42 PM, Bruce Momjian br...@momjian.us wrote:
27 hours later, done. ? I ran all the tests outlined in the pgindent
README.
What's with things like:
-void _PG_init(void);
On 04/10/2011 12:11 PM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Sun, Apr 10, 2011 at 11:55 AM, Greg Starkgsst...@mit.edu wrote:
Note that in the last one someone carefully made the variable names
line up and pgindent is changing the spacing to an arbitrary amount.
Andrew Dunstan and...@dunslane.net writes:
On 04/10/2011 12:11 PM, Tom Lane wrote:
What I was a bit surprised by is the volume of changes in wparser_def.c
--- so far as I can see, that file hardly changed since 9.0, so why did
pgindent suddenly whack it around so much? The other files that
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/10/2011 12:11 PM, Tom Lane wrote:
What I was a bit surprised by is the volume of changes in wparser_def.c
--- so far as I can see, that file hardly changed since 9.0, so why did
pgindent suddenly whack it around so much?
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 has changed the way it
So, we talked about running pgindent a few weeks ago, but reading over
the thread, I guess we're still waiting for Andrew to update the list
of typedefs?
It would be really nice to get this done. Andrew, is there any chance
you can knock that out?
--
Robert Haas
EnterpriseDB:
On 04/08/2011 06:05 PM, Robert Haas wrote:
So, we talked about running pgindent a few weeks ago, but reading over
the thread, I guess we're still waiting for Andrew to update the list
of typedefs?
It would be really nice to get this done. Andrew, is there any chance
you can knock that out?
On Fri, Apr 8, 2011 at 8:05 PM, Andrew Dunstan and...@dunslane.net wrote:
On 04/08/2011 06:05 PM, Robert Haas wrote:
So, we talked about running pgindent a few weeks ago, but reading over
the thread, I guess we're still waiting for Andrew to update the list
of typedefs?
It would be really
On 04/08/2011 10:12 PM, Robert Haas wrote:
On Fri, Apr 8, 2011 at 8:05 PM, Andrew Dunstanand...@dunslane.net wrote:
On 04/08/2011 06:05 PM, Robert Haas wrote:
So, we talked about running pgindent a few weeks ago, but reading over
the thread, I guess we're still waiting for Andrew to update
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 has changed the way it does objdump. This is
Somehow, pgindent appears to have this approach to push lines that are
longer than the defined line length limit back to the left to make it
fit. That results in something like this:
printfPQExpBuffer(buf,
SELECT n.nspname as \%s\,\n
p.proname AS
Peter Eisentraut wrote:
Somehow, pgindent appears to have this approach to push lines that are
longer than the defined line length limit back to the left to make it
fit. That results in something like this:
printfPQExpBuffer(buf,
SELECT n.nspname as \%s\,\n
Bruce Momjian br...@momjian.us writes:
Peter Eisentraut wrote:
Somehow, pgindent appears to have this approach to push lines that are
longer than the defined line length limit back to the left to make it
fit. That results in something like this:
Can we get rid of this behavior?
I think
On mån, 2010-04-19 at 21:25 -0400, Bruce Momjian wrote:
Oh, that is an interesting example. What the code does is if there are
several spaces and the next word is on a tab stop, the spaces are
convered to tabs, except if we are in a string. This conversion is done
by 'entab' which we
Peter Eisentraut wrote:
On tor, 2010-04-15 at 20:56 -0400, Bruce Momjian wrote:
Peter Eisentraut wrote:
Apparently, pgindent replaces multiple spaces in comments by a tab
(possibly subject to additional logic). An example among thousands:
On tor, 2010-04-15 at 20:56 -0400, Bruce Momjian wrote:
Peter Eisentraut wrote:
Apparently, pgindent replaces multiple spaces in comments by a tab
(possibly subject to additional logic). An example among thousands:
Apparently, pgindent replaces multiple spaces in comments by a tab
(possibly subject to additional logic). An example among thousands:
Peter Eisentraut wrote:
Apparently, pgindent replaces multiple spaces in comments by a tab
(possibly subject to additional logic). An example among thousands:
Tom Lane wrote:
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
Because the typedef list supplied by Andrew includes FD_SET as a
typedef. :-O See
Andrew Dunstan wrote:
Following up Tom's complaint about behaviour of pgindent, I have been
wrestling with it a bit. I noticed several things.
First awk on my box spits out fairly useless warnings about regular
expressions containing a literal '\*'. These warnings are silenced by
Bruce Momjian wrote:
Tom Lane wrote:
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
Because the typedef list supplied by Andrew includes
Andrew Dunstan and...@dunslane.net writes:
I've committed a fix to pgindent for this. Do we want to rerun pgindent
for these files?:
I think the plan is to redo pgindent near the end of beta. There's
probably no need to do it right now.
regards, tom lane
--
Sent via
Andrew Dunstan wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
Because the typedef
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I've committed a fix to pgindent for this. Do we want to rerun pgindent
for these files?:
I think the plan is to redo pgindent near the end of beta. There's
probably no need to do it right now.
Sure, sounds like a plan.
--
Following up Tom's complaint about behaviour of pgindent, I have been
wrestling with it a bit. I noticed several things.
First awk on my box spits out fairly useless warnings about regular
expressions containing a literal '\*'. These warnings are silenced by
replacing those with '[*]',
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Why has pgindent decided to screw up all the FD_SET calls in our code?
See for example
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.188;r2=1.189
This appears to be due to this on mingw:
I propose that we create a file containing the list of patterns to
exclude from pgindent runs. It would look like this:
#list of file patterns to exclude from pg_indent runs
/s_lock\.h$
/ecpg/test/expected/
/snowball/libstemmer/
/ecpg/include/(sqlda|sqltypes)\.h$
On Wed, Mar 31, 2010 at 10:27:03AM -0400, Andrew Dunstan wrote:
I propose that we create a file containing the list of patterns to
exclude from pgindent runs. It would look like this:
#list of file patterns to exclude from pg_indent runs
/s_lock\.h$
/ecpg/test/expected/
Andrew Dunstan wrote:
I propose that we create a file containing the list of patterns to
exclude from pgindent runs. It would look like this:
#list of file patterns to exclude from pg_indent runs
/s_lock\.h$
/ecpg/test/expected/
/snowball/libstemmer/
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
The reason this is like this is that the indent binary modifies the
prototype exactly like the function definition, and then the awk program
that's used in the pipeline pulls up the second line:
# Move prototype names
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Um, sorry, no reason to do which?
No reason not to leave prototypes alone in the AWK code. Isn't the
style emitted by indent good enough already? The comment that ctags
needs it is probably outdated (I know my ctags, the
On Wed, Aug 12, 2009 at 9:35 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Um, sorry, no reason to do which?
No reason not to leave prototypes alone in the AWK code. Isn't the
style emitted by indent good enough already? The
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 6:52 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Only if they aren't applied by then. One reason that we normally only
run pgindent at the end of the devel cycle is that that's when
(presumably) the smallest amount of patches remain
Greg Stark gsst...@mit.edu writes:
What would happen if we ran pgindent immediately after every commit?
So nobody would ever see a checkout that wasn't pgindent-clean?
The only losers I see would be people working on multi-part patches.
... which we're trying to encourage ...
Actually, the
Robert Haas robertmh...@gmail.com writes:
What is a bit frustrating to me is that a number of Tom's changes to
the first two patches were trivial whitespace changes that required me
to rebase for no obvious reason. Either those changes were made
accidentally as Tom was fooling around with
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 11, 2009 at 10:08 PM, Tom Lanet...@sss.pgh.pa.us wrote:
If that's not it, you'd need to mention details.
Well, one thing I've noticed is that when a function prototype wraps
around to the next line, you often change the number of spaces in
Tom Lane escribió:
Ah. That's a bit idiosyncratic to pgindent. What it does for a
function definition makes sense, I think: it lines up all the
parameters to start in the same column:
static int
myfunction(int foo,
int bar)
What is not obvious is that the same amount of
Alvaro Herrera alvhe...@commandprompt.com writes:
The reason this is like this is that the indent binary modifies the
prototype exactly like the function definition, and then the awk program
that's used in the pipeline pulls up the second line:
# Move prototype names to the same line as
On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
Peter Eisentraut pete...@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
Peter Eisentraut wrote:
On Wednesday 10 June 2009 23:54:41 Tom Lane wrote:
Peter Eisentraut pete...@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
Andrew Dunstan and...@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
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
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
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
Bruce Momjian br...@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
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
--
Sent via pgsql-hackers mailing list
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
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
Merlin Moncure mmonc...@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 Thu, Jun 11, 2009 at 2:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@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
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
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
Simon Riggs si...@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
Tom Lane wrote:
Bruce Momjian br...@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
Bruce Momjian br...@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
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
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
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
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@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
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
Bruce Momjian br...@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
Tom Lane wrote:
Bruce Momjian br...@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
Bruce Momjian br...@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
Tom Lane wrote:
Bruce Momjian br...@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
Bruce Momjian br...@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.
Tom Lane wrote:
Bruce Momjian br...@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
Andrew Dunstan wrote:
Tom Lane wrote:
Bruce Momjian br...@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
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
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 */
...
Greg Stark st...@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
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?
--
Sent via
Peter Eisentraut pete...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
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 */
Tom Lane wrote:
Greg Stark st...@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
Tom Lane wrote:
Peter Eisentraut pete...@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 br...@momjian.ushttp://momjian.us
EnterpriseDB
On Wednesday 10 June 2009 22:50:15 Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@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.
Peter Eisentraut pete...@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
On Wed, Jun 10, 2009 at 9:54 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@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
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
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
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
Andrew Dunstan and...@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
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 br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life
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
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
Bruce Momjian br...@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
Tom Lane wrote:
Bruce Momjian br...@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
Tom Lane wrote:
Bruce Momjian br...@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
Bruce Momjian br...@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
Tom Lane wrote:
Bruce Momjian br...@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
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
I wonder if this can be improved:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/planner.h.diff?r1=1.41;r2=1.42
Similar examples can be found elsewhere ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
I have commited a change to src/tools/find_typedef that should allow it
to run under Linux. The only difference I see is that some unused
typedefs do not appear in the Linux version.
---
Alvaro Herrera wrote:
Bruce
Bruce Momjian wrote:
I have commited a change to src/tools/find_typedef that should allow it
to run under Linux. The only difference I see is that some unused
typedefs do not appear in the Linux version.
However, I think pgindent only cares about the typedef references, not
the definitions,
Alvaro Herrera wrote:
I don't know how to make it output the symbol names like it seems to do
for you.
Having the typedef list in the script itself seems like a barrier for
other people to contribute to this thing. I wonder if that can be
changed so that the typedef is on a separate list.
101 - 200 of 297 matches
Mail list logo
