Re: [HACKERS] Compiler warning in costsize.c

On 11 April 2017 at 12:53, Michael Paquier wrote: > On Tue, Apr 11, 2017 at 4:02 AM, Robert Haas wrote: >> On Mon, Apr 10, 2017 at 2:09 PM, Tom Lane wrote: >>> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)

Re: [HACKERS] compiler warning with VS 2017

Petr Jelinek writes: > On 05/05/17 16:56, Tom Lane wrote: >> So the comment should be something like "if the column is unchanged, >> we should not attempt to access its value beyond this point. To >> help catch any such attempts, set the string to NULL" ? > Yes

Re: [HACKERS] compiler warning with VS 2017

On 05/05/17 16:56, Tom Lane wrote: > Petr Jelinek writes: >> On 05/05/17 06:50, Tom Lane wrote: >>> Actually, looking around a bit there, it's not even clear why >>> we should be booby-trapping the value of an unchanged column in >>> the first place. So I'd say that

Re: [HACKERS] compiler warning with VS 2017

Petr Jelinek writes: > On 05/05/17 06:50, Tom Lane wrote: >> Actually, looking around a bit there, it's not even clear why >> we should be booby-trapping the value of an unchanged column in >> the first place. So I'd say that not only is the code dubious >> but the

Re: [HACKERS] compiler warning with VS 2017

On 05/05/17 06:50, Tom Lane wrote: > Haribabu Kommi writes: >> I am getting a compiler warning when I build the latest HEAD PostgreSQL with >> visual studio 2017. >> The code at the line is, >> tuple->values[i] = (char *) (Size)0xdeadbeef; /* make bad usage more obvious

Re: [HACKERS] compiler warning with VS 2017

Haribabu Kommi writes: > I am getting a compiler warning when I build the latest HEAD PostgreSQL with > visual studio 2017. > The code at the line is, > tuple->values[i] = (char *) (Size)0xdeadbeef; /* make bad usage more obvious > */ Yeah, you're not the first to

[HACKERS] compiler warning with VS 2017

I am getting a compiler warning when I build the latest HEAD PostgreSQL with visual studio 2017. src/backend/replication/logical/proto.c(482): warning C4312: 'type cast': conversion from 'unsigned int' to 'char *' of greater size Details of the warning is available in the link [1]. The code at

Re: [HACKERS] Compiler warning in costsize.c

On Tue, Apr 11, 2017 at 4:02 AM, Robert Haas wrote: > On Mon, Apr 10, 2017 at 2:09 PM, Tom Lane wrote: >> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: >>> Why bother with the 'rte' variable at all if it's only used for the >>>

Re: [HACKERS] Compiler warning in costsize.c

On Mon, Apr 10, 2017 at 2:09 PM, Tom Lane wrote: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: >> Why bother with the 'rte' variable at all if it's only used for the >> Assert()ing the rtekind? > > That was proposed a few messages back. I don't like

Re: [HACKERS] Compiler warning in costsize.c

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Why bother with the 'rte' variable at all if it's only used for the > Assert()ing the rtekind? That was proposed a few messages back. I don't like it because it makes these functions look different from the other

Re: [HACKERS] Compiler warning in costsize.c

Robert Haas writes: > On Mon, Apr 10, 2017 at 8:30 AM, Michael Paquier > wrote: >> On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote: >>> I wonder if we shouldn't just do >>> ... >>> and eat the "useless" calculation of rte. >

Re: [HACKERS] Compiler warning in costsize.c

Tom Lane writes: > I wonder if we shouldn't just do > > RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY; > ListCell *lc; > > /* Should only be applied to base relations that are subqueries */ > Assert(rel->relid > 0); > -#ifdef USE_ASSERT_CHECKING >

Re: [HACKERS] Compiler warning in costsize.c

On Mon, Apr 10, 2017 at 8:30 AM, Michael Paquier wrote: > On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote: >> I wonder if we shouldn't just do >> >> RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY; >> ListCell *lc; >> >> /*

Re: [HACKERS] Compiler warning in costsize.c

On Mon, Apr 10, 2017 at 9:05 PM, Tom Lane wrote: > I wonder if we shouldn't just do > > RangeTblEntry *rte PG_USED_FOR_ASSERTS_ONLY; > ListCell *lc; > > /* Should only be applied to base relations that are subqueries */ > Assert(rel->relid >

Re: [HACKERS] Compiler warning in costsize.c

David Rowley writes: > On 8 April 2017 at 04:42, Tom Lane wrote: >> BTW, is it really true that only these two places produce such warnings >> on MSVC? I see about three dozen uses of PG_USED_FOR_ASSERTS_ONLY in our >> tree, and I'd have

Re: [HACKERS] Compiler warning in costsize.c

On 8 April 2017 at 04:42, Tom Lane wrote: > I'd be happier with something along the line of > > RangeTblEntry *rte; > ListCell *lc; > > /* Should only be applied to base relations that are subqueries */ > Assert(rel->relid > 0); > rte

Re: [HACKERS] Compiler warning in costsize.c

Michael Paquier writes: > Bah. This actually fixes nothing. Attached is a different patch that > really addresses the problem, by removing the variable because we > don't want planner_rt_fetch() to run for non-Assert builds. I don't really like any of these fixes,

Re: [HACKERS] Compiler warning in costsize.c

On Fri, Apr 7, 2017 at 12:38 AM, Michael Paquier wrote: > On Tue, Apr 4, 2017 at 9:42 PM, Michael Paquier > wrote: >> On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote: >>> (I'm personally not that much in love with

Re: [HACKERS] Compiler warning in costsize.c

On Tue, Apr 4, 2017 at 9:42 PM, Michael Paquier wrote: > On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote: >> (I'm personally not that much in love with PG_USED_FOR_ASSERTS_ONLY, >> because it tends to confuse pgindent.) > > I would be incline to just

Re: [HACKERS] Compiler warning in costsize.c

On Wed, Apr 5, 2017 at 2:54 AM, Tom Lane wrote: > Michael Paquier writes: >> In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can >> generate warnings. Here is for example with MSVC: >> src/backend/optimizer/path/costsize.c(4520):

Re: [HACKERS] Compiler warning in costsize.c

Michael Paquier writes: > In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can > generate warnings. Here is for example with MSVC: > src/backend/optimizer/path/costsize.c(4520): warning C4101: 'rte' : > unreferenced local variable

Re: [HACKERS] Compiler warning in costsize.c

On Tue, Apr 4, 2017 at 7:03 PM, David Rowley wrote: > On 4 April 2017 at 16:22, Michael Paquier wrote: >> Hi all, >> >> In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can >> generate warnings. Here is for example with MSVC:

Re: [HACKERS] Compiler warning in costsize.c

On 4 April 2017 at 16:22, Michael Paquier wrote: > Hi all, > > In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can > generate warnings. Here is for example with MSVC: > src/backend/optimizer/path/costsize.c(4520): warning C4101: 'rte' : > unreferen >

[HACKERS] Compiler warning in costsize.c

Hi all, In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can generate warnings. Here is for example with MSVC: src/backend/optimizer/path/costsize.c(4520): warning C4101: 'rte' : unreferen ced local variable [C:\Users\ioltas\git\postgres\postgres.vcxproj]

Re: [HACKERS] compiler warning in set_tablefunc_size_estimates

On Thu, Mar 9, 2017 at 4:39 PM, Tom Lane wrote: > Robert Haas writes: >> I tried a non-cassert compile on a machine that has a pickier compiler >> than my laptop, and got: > >> costsize.c: In function ‘set_tablefunc_size_estimates’: >>

Re: [HACKERS] compiler warning in set_tablefunc_size_estimates

Robert Haas writes: > I tried a non-cassert compile on a machine that has a pickier compiler > than my laptop, and got: > costsize.c: In function ‘set_tablefunc_size_estimates’: > costsize.c:4574:17: error: variable ‘rte’ set but not used >

[HACKERS] compiler warning in set_tablefunc_size_estimates

I tried a non-cassert compile on a machine that has a pickier compiler than my laptop, and got: costsize.c: In function ‘set_tablefunc_size_estimates’: costsize.c:4574:17: error: variable ‘rte’ set but not used [-Werror=unused-but-set-variable] That appears to be a legitimate gripe. Perhaps:

Re: [HACKERS] Compiler warning

On Dec 24, 2016 01:21, "Bruce Momjian" wrote: I am seeing this compiler warning in the 9.4 branch: 9.4: basebackup.c:1284:6: warning: variable 'wait_result' set but not used [-Wunused-but-set-variable] This is on Debian Jessie with gcc version 4.9.2. It is from this

[HACKERS] Compiler warning

I am seeing this compiler warning in the 9.4 branch: 9.4: basebackup.c:1284:6: warning: variable 'wait_result' set but not used [-Wunused-but-set-variable] This is on Debian Jessie with gcc version 4.9.2. It is from this commit: commit f6508827afe76b2c3735a9ce073620e708d60c79

Re: [HACKERS] compiler warning read_objtype_from_string()

Tom Lane wrote: > I do not think you should assume that the compiler is smart enough to > deduce that, nor that all compilers even know ereport(ERROR) doesn't > return. Personally I don't see the point of the "type" variable at > all, anyway. I would have written this as > > [code] Makes

Re: [HACKERS] compiler warning read_objtype_from_string()

Alvaro Herrera writes: > Peter Eisentraut wrote: >> I'm getting the following compiler warning (using nondefault >> optimization options): >> objectaddress.c: In function 'read_objtype_from_string': >> objectaddress.c:2309:9: error: 'type' may be used uninitialized in

Re: [HACKERS] compiler warning read_objtype_from_string()

Peter Eisentraut wrote: > I'm getting the following compiler warning (using nondefault > optimization options): > > objectaddress.c: In function 'read_objtype_from_string': > objectaddress.c:2309:9: error: 'type' may be used uninitialized in this > function [-Werror=maybe-uninitialized] >

[HACKERS] compiler warning read_objtype_from_string()

I'm getting the following compiler warning (using nondefault optimization options): objectaddress.c: In function 'read_objtype_from_string': objectaddress.c:2309:9: error: 'type' may be used uninitialized in this function [-Werror=maybe-uninitialized] return type; The comment for the function

[HACKERS] Compiler warning in pg_am changes

Hi, I've attached a small patch to fix new compiler warning which is new as of 65c5fcd3 -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services amcostestimate_cast.patch Description: Binary data -- Sent via pgsql-hackers

Re: [HACKERS] Compiler warning in pg_am changes

David Rowley writes: > I've attached a small patch to fix new compiler warning which is new as of > 65c5fcd3 Pushed, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] Compiler warning

Commit 7e2a18a9 must have caused this compiler warning which I now see on the master branch with my standard release build settings: gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing

Re: [HACKERS] Compiler warning

Peter Geoghegan writes: > Commit 7e2a18a9 must have caused this compiler warning which I now see > on the master branch with my standard release build settings: [ scratches head... ] Dunno why my compiler didn't complain about that. Will fix it in a bit.

Re: [HACKERS] Compiler warning about overflow in xlog.c

Petr Jelinek p...@2ndquadrant.com writes: my compiler complains about overflow in xlog.c. Yeah, Peter E. reported this yesterday. Since Heikki didn't do anything about that yet, I pushed your fix. regards, tom lane -- Sent via pgsql-hackers mailing list

[HACKERS] Compiler warning about overflow in xlog.c

Hi, my compiler complains about overflow in xlog.c. There is variable defined as char partialfname[MAXFNAMELEN]; but is used as snprintf(partialfname, MAXPGPATH, %s.partial, origfname); There is no practical issue as the actual filename length is never over MAXFNAMELEN even with the

Re: [HACKERS] Compiler warning in master branch

David Rowley dgrowle...@gmail.com wrote: On Mon, Nov 10, 2014 at 4:31 PM, Peter Geoghegan p...@heroku.com wrote: I see this when I build at -O2 from master's tip: brin_revmap.c: In function ‘brinRevmapExtend’: brin_revmap.c:113:14: error: variable ‘mapBlk’ set but not used

[HACKERS] Compiler warning in master branch

I see this when I build at -O2 from master's tip: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Werror -I../../../../src/include

Re: [HACKERS] Compiler warning in master branch

On Mon, Nov 10, 2014 at 4:31 PM, Peter Geoghegan p...@heroku.com wrote: I see this when I build at -O2 from master's tip: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv

[HACKERS] compiler warning in UtfToLocal and LocalToUtf (conv.c)

Hello, in the current master head (4cbe3ac3e86790d05c569de4585e5075a62a9b41), I've noticed the compiler warnings in src/backend/utils/mb/conv.c conv.c: In function ‘UtfToLocal’: conv.c:252:23: error: ‘iutf’ may be used uninitialized in this function [-Werror=maybe-uninitialized] ... conv.c: In

Re: [HACKERS] compiler warning in UtfToLocal and LocalToUtf (conv.c)

Karol Trzcionka karl...@gmail.com writes: in the current master head (4cbe3ac3e86790d05c569de4585e5075a62a9b41), I've noticed the compiler warnings in src/backend/utils/mb/conv.c Hm, what compiler version are you using? I've never seen such a warning (and that code hasn't changed in some

Re: [HACKERS] compiler warning in UtfToLocal and LocalToUtf (conv.c)

W dniu 19.07.2013 02:42, Tom Lane pisze: Hm, what compiler version are you using? I've never seen such a warning (and that code hasn't changed in some time). gcc version 4.8.1 20130612 (Red Hat 4.8.1-2) (GCC) Regards, Karol -- Sent via pgsql-hackers mailing list

Re: [HACKERS] compiler warning

Magnus Hagander wrote: On Thu, Feb 3, 2011 at 04:40, Bruce Momjian br...@momjian.us wrote: I am seeing the following compiler warning for the past few days: ? ? ? ?basebackup.c:213: warning: variable `ptr' might be clobbered by ? ? ? ?`longjmp' or `vfork' and I see this comment in the

Re: [HACKERS] compiler warning

On Thu, Feb 3, 2011 at 04:40, Bruce Momjian br...@momjian.us wrote: I am seeing the following compiler warning for the past few days:        basebackup.c:213: warning: variable `ptr' might be clobbered by        `longjmp' or `vfork' and I see this comment in the file:        /*         *

[HACKERS] compiler warning

I am seeing the following compiler warning for the past few days: basebackup.c:213: warning: variable `ptr' might be clobbered by `longjmp' or `vfork' and I see this comment in the file: /* * Actually do a base backup for the specified tablespaces. *

[HACKERS] compiler warning

A little while ago, I saw a compiler warning creep in: In file included from gram.y:11202: scan.c: In function ‘yy_try_NUL_trans’: scan.c:15765: warning: unused variable ‘yyg’ I know there were some changes to minimum versions, but I think I have those versions (listed below). I don't know if

Re: [HACKERS] compiler warning

Jeff Davis pg...@j-davis.com writes: A little while ago, I saw a compiler warning creep in: In file included from gram.y:11202: scan.c: In function ‘yy_try_NUL_trans’: scan.c:15765: warning: unused variable ‘yyg’ Yeah, this is a bogosity in the current release of flex.

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400: Zdenek Kotala zdenek.kot...@sun.com writes: I attached another cleanup patch which fixes following warnings reported by Sun Studio: I'm not too impressed with any of these. The proposed added initializers just increase future maintenance

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Tom Lane píše v čt 28. 05. 2009 v 11:57 -0400: ). AFAICS, Sun's compiler is just too stupid and shouldn't be emitting this warning. Perhaps the right response is to file a bug report against the compiler. I checked it and it is already know bug. It is new lint style check in Sun Studio

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Zdenek Kotala zdenek.kot...@sun.com writes: Tom Lane píše v čt 28. 05. 2009 v 11:42 -0400: The proposed signature change on psql_completion is going to replace a warning on your system with outright failures on other people's. I check readline and definition is still same at least from

[HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

I attached another cleanup patch which fixes following warnings reported by Sun Studio: zic.c, line 1534: warning: const object should have initializer: tzh0 dynloader.c, line 7: warning: empty translation unit pgstat.c, line 666: warning: const object should have initializer: all_zeroes

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote: I attached another cleanup patch which fixes following warnings reported by Sun Studio: ... preproc.c, line 39569: warning: pointer expression or its operand do not point to the same object yyerror_range, result is undefined and

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Michael Meskes píše v čt 28. 05. 2009 v 13:33 +0200: On Thu, May 28, 2009 at 11:11:20AM +0200, Zdenek Kotala wrote: I attached another cleanup patch which fixes following warnings reported by Sun Studio: ... preproc.c, line 39569: warning: pointer expression or its operand do not

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote: Problem is with YYLLOC_DEFAULT. When I look on macro definition #define YYLLOC_DEFAULT(Current, Rhs, N) \ Current.first_line = Rhs[1].first_line; \ Current.first_column = Rhs[1].first_column;\

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Michael Meskes píše v čt 28. 05. 2009 v 14:47 +0200: On Thu, May 28, 2009 at 01:51:07PM +0200, Zdenek Kotala wrote: Problem is with YYLLOC_DEFAULT. When I look on macro definition #define YYLLOC_DEFAULT(Current, Rhs, N) \ Current.first_line = Rhs[1].first_line; \

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Zdenek Kotala zdenek.kot...@sun.com writes: I attached another cleanup patch which fixes following warnings reported by Sun Studio: I'm not too impressed with any of these. The proposed added initializers just increase future maintenance effort without solving any real problem (since the

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

Michael Meskes mes...@postgresql.org writes: I have to admit that those version look strikingly unsimilar to me. There is no reference to Rhs[N] in our macro at all. But then I have no idea whether this is needed. The default version of the macro is intended to track both the starting and

Re: [HACKERS] Compiler warning

Peter Eisentraut wrote: Note that applying this patch would introduce a double-translation issue of the sort that you had complained about a while ago. I'm unsure which way to proceed here. Hmm, the patch looks fine to me. The strings are marked with gettext_noop() in the array, and passed

Re: [HACKERS] Compiler warning

On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote: Peter Eisentraut wrote: Note that applying this patch would introduce a double-translation issue of the sort that you had complained about a while ago. I'm unsure which way to proceed here. Hmm, the patch looks fine to me. The

Re: [HACKERS] Compiler warning

Peter Eisentraut pete...@gmx.net writes: On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote: Hmm, the patch looks fine to me. The strings are marked with gettext_noop() in the array, and passed through _() when used in errmsg. But his patch changes that to errhint(%s,

Re: [HACKERS] Compiler warning

On Thursday 21 May 2009 14:29:51 Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: On Thursday 21 May 2009 10:01:59 Heikki Linnakangas wrote: Hmm, the patch looks fine to me. The strings are marked with gettext_noop() in the array, and passed through _() when used in errmsg. But

Re: [HACKERS] Compiler warning

Fujii Masao wrote: I encountered the following compiler warning in 8.4dev. Attached is the patch to fix this problem. Is this worth committing? -- tablecmds.c: In function 'DropErrorMsgWrongType': tablecmds.c:606: warning: format not a string literal and no format arguments

Re: [HACKERS] Compiler warning

Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Hmm, it is a false alarm, but would be nice to have a warning-free build. I don't see that warning here on gcc 4.3.3 by default, but I do when I set -Wformat-security. I presume you had that set as well. Would it be worth having

Re: [HACKERS] Compiler warning

On Wednesday 20 May 2009 16:24:21 Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Hmm, it is a false alarm, but would be nice to have a warning-free build. I don't see that warning here on gcc 4.3.3 by default, but I do when I set -Wformat-security. I presume

[HACKERS] Compiler warning

Hi, I encountered the following compiler warning in 8.4dev. Attached is the patch to fix this problem. Is this worth committing? -- tablecmds.c: In function 'DropErrorMsgWrongType': tablecmds.c:606: warning: format not a string literal and no format arguments --

[HACKERS] Compiler warning with 'fast' variable

Any idea why I am seeing this warning with the new pg_start_backup() 'fast' flag? xlog.c:6917: warning: variable `fast' might be clobbered by `longjmp' or `vfork' The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is with gcc version 2.95.3. -- Bruce Momjian

Re: [HACKERS] Compiler warning with 'fast' variable

Bruce Momjian br...@momjian.us writes: Any idea why I am seeing this warning with the new pg_start_backup() 'fast' flag? xlog.c:6917: warning: variable `fast' might be clobbered by `longjmp' or `vfork' The line is in a PG_ENSURE_ERROR_CLEANUP() block. This is with gcc version

Re: [HACKERS] Compiler warning with 'fast' variable

Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Any idea why I am seeing this warning with the new pg_start_backup() 'fast' flag? xlog.c:6917: warning: variable `fast' might be clobbered by `longjmp' or `vfork' The line is in a PG_ENSURE_ERROR_CLEANUP() block. This

Re: [HACKERS] Compiler warning with 'fast' variable

Bruce Momjian br...@momjian.us writes: Tom Lane wrote: We could stick a volatile on it but I'd like to find out why this particular variable seems to need that. You ready for this; changing 'bool' to 'int' supressed the warning: int fast = PG_GETARG_BOOL(1); Well, that's a

Re: [HACKERS] Compiler warning with 'fast' variable

Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Tom Lane wrote: We could stick a volatile on it but I'd like to find out why this particular variable seems to need that. You ready for this; changing 'bool' to 'int' supressed the warning: int fast = PG_GETARG_BOOL(1);

Re: [HACKERS] Compiler warning in ecpglib/execute.c

On Tue, Feb 03, 2009 at 04:06:39PM -0300, Alvaro Herrera wrote: Note that spoonbill is still red. This animal is special because it uses some peculiar malloc flags. Not just spoonbill, five of them are. Without access to a failing machine this is difficult to debug. I found some missing error

Re: [HACKERS] Compiler warning in ecpglib/execute.c

On Mon, Feb 02, 2009 at 02:56:18PM -0500, Tom Lane wrote: CVS HEAD is producing ... Thanks for the note, I missed this copypaste error of mine. Fixed in HEAD. This should alos make the buildfarm green again. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: [HACKERS] Compiler warning in ecpglib/execute.c

Michael Meskes wrote: On Mon, Feb 02, 2009 at 02:56:18PM -0500, Tom Lane wrote: CVS HEAD is producing ... Thanks for the note, I missed this copypaste error of mine. Fixed in HEAD. This should alos make the buildfarm green again. Note that spoonbill is still red. This animal is special

[HACKERS] Compiler warning in ecpglib/execute.c

CVS HEAD is producing execute.c: In function 'ecpg_store_result': execute.c:394: warning: 'act_tuple' may be used uninitialized in this function It looks to me like this is an actual bug, not just the compiler being insufficiently smart to prove the variable is set before use.

[HACKERS] Compiler warning (V7.1 plpgsql)

It's nothing but unused definitions. PostgreSQL7.1 compiles and works for me. I got following warnings for PL/PgSQL make[2]: `/opt/rh7/postgresql/postgresql-7.1/src/pl' make[3]: `/opt/rh7/postgresql/postgresql-7.1/src/pl/plpgsql' make -C src all make[4]: