On 2/10/2010 7:12 AM, Tom Lane wrote:
Kurt, you seem to be more or less impervious to advice :-(.
Thank you for reviewing my patch. It is a rare honor to
have my personal qualities reviewed here as well.
Since this forum is archived for posterity, I suppose I
must point out that I have in fac
On 12/16/2009 8:21 AM, Tom Lane wrote:
I would only suggest that the cleanest coding would be
#ifdef USE_INLINE
static inline foo(...) ...
#else
... non-inline definition of foo
#endif
ie, go ahead and rely on autoconf's definition (if any) of "inline
On 12/16/2009 8:40 AM, Tom Lane wrote:
Alvaro Herrera writes:
IIRC Kurt was also on about getting rid of some ugly macros that could
instead be coded as inline functions (fastgetattr for example)
I'd just bounce that as useless activity. If they are macros now,
and work, the only possible ef
On 1/19/2010 8:01 AM, Peter Eisentraut wrote:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
We have some existing inline functions in .c files. These can be
more complicated, so it might be ok if the compiler decides to
leave them out-of
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
On mån, 2010-01-18 at 16:34 -0800, Kurt Harriman wrote:
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline.
Hmm, but forceinline is not the same as inline. Are we confident
On 1/18/2010 4:42 PM, Tom Lane wrote:
I think including MSVC in the set of compilers targeted by a configure
test is just a waste of code. It's more likely to confuse people than
help them.
Ok, I have taken that out, and instead put the right stuff for MSVC into
pg_config.h.win32.
Regards, ..
On 1/19/2010 8:43 AM, Tom Lane wrote:
Peter Eisentraut writes:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
Or compiler switches could be set to disable all such warnings
globally. Warning 4514 is specific to inline functions; so
maybe it would be alright to keep it turned off
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
On mån, 2010-01-18 at 16:34 -0800, Kurt Harriman wrote:
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline.
Hmm, but forceinline is not the same as inline. Are we confident
On 1/17/2010 11:27 AM, Peter Eisentraut wrote:
I have found an Autoconf macro that checks whether the compiler properly
supports C99 inline semantics. This would allow us to replace the
__GNUC__ conditional with HAVE_C99_INLINE, in this case.
At present, PostgreSQL uses only "static inline", w
On 1/18/2010 4:42 PM, Tom Lane wrote:
> Kurt Harriman writes:
>> c) Use configure to automate the testing of each build environment
>>in situ.
>
>> The third alternative adapts to new or little-known platforms
>> with little or no manual interventi
On 1/18/2010 1:20 PM, Peter Eisentraut wrote:
I seem to recall that somewhere else it was said that MSVC produces
warnings on unused static inline functions. Am I mistaken?
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline
On 12/16/2009 7:10 AM, Tom Lane wrote:
the project policy is to not require any compiler features not found
> in C89.
Is there somewhere a compendium of such policies which
fledgling hackers should consult to avoid embarrassment?
Regards,
... kurt
--
Sent via pgsql-hackers mailing list (pgsq
On 12/15/2009 9:42 PM, Robert Haas wrote:
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman wrote:
Your worry ii) can be ignored, managing to compile on such
compilers is already overachievement.
I think so too. With your opinion added to mine, do we constitute a
consensus of the pg community
[Please ignore the previous incomplete version of this reply, which I
sent by mistake. Sorry for the list noise.]
On 12/15/2009 2:09 PM, Marko Kreen wrote:
>
> Oh. Ok then. Force-inline seems better fix as we may want to use
> it for other reasons too (converting big macros).
>
> So it seems l
On 12/15/2009 2:09 PM, Marko Kreen wrote:
Oh. Ok then. Force-inline seems better fix as we may want to use
it for other reasons too (converting big macros).
So it seems like a good moment to solve it for gcc too.
Is ordinary inlining not sufficient?
If deluxe inlining is something that mig
On 12/15/2009 1:31 PM, Marko Kreen wrote:
Do you have actual proof that MSVC launches warnings on unused
"static inline" functions? Not "static", but "static inline".
Yes, I tried it, and that's why I did it this way.
If yes, indeed we need to fix it. MSVC is broken then, but it does
not ma
On 12/15/2009 4:05 AM, Marko Kreen wrote:
On 12/15/09, Kurt Harriman wrote:
Attached is a revised patch, offered for the 2010-01 commitfest.
It's also available in my git repository in the "submitted" branch:
http://git.postgresql.org/gitweb?p=users/harriman/share.git;a=
Bruce Momjian wrote:
Peter Eisentraut wrote:
On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote:
I thought one problem was that inline is a suggestion that the compiler
can ignore, while macros have to be implemented as specified.
Sure, but one could argue that a compiler that doesn't supp
Tom Lane wrote:
Kurt Harriman writes:
(Does anybody still use a C compiler that doesn't support
inline functions?)
The question isn't so much that, it's whether the compiler supports
inline functions with the same behavior as gcc.
With this patch, if the compiler doe
s/list.c | 10 --
src/backend/utils/mmgr/mcxt.c |9 -----
src/include/nodes/pg_list.h |4 ++--
src/include/utils/palloc.h|8
5 files changed, 18 insertions(+), 17 deletions(-)
--- Kurt Harriman 2009-11-29 08:22:05 -0800
diff --git
Tom Lane wrote:
Kurt Harriman writes:
However, probably an easier alternative would be to have
just one buildfarm machine do a nightly build configured
with the --enable-cplusplus option.
There is no such option, and won't be.
Yours is the first comment anyone has posted to the
Tom Lane wrote:
if we fix some or all of the headers, what's the
plan for making sure that they stay fixed? Without a C++ buildfarm
member I think the chances of future breakage approach certainty.
Actually, after re-reading the whole earlier thread I see that we did
think of a possible answer
Is there anything in the source that would necessarily preclude using the
C++ compiler to build *all* the code?
No. Most of the source files would need a sprinkling of
tiny changes: typically only a handful of casts need to be
added. Some files would need more widespread (but still
trivial) ch
Tom Lane wrote:
Kurt Harriman <[EMAIL PROTECTED]> writes:
[ make the backend C++-compilable ]
This has been proposed before, and rejected before, and I don't believe
the arguments have changed in the least.
Hi Tom,
Of the series of four patches, the first two (c++reserved and
Peter Eisentraut wrote:
FYI, we have received patches morally equivalent to yours many times
over the years, and they have all been rejected. You might want to
review the archives about that.
Hi Peter,
I went back as far as 2005 in the archives, and found only this thread
covering similar te
ith almost any language / library / system call / network
protocol / etc - notably, PostgreSQL's own tree structures and
data types.
Thanks for your comments; I hope I've responded adequately.
In any case, I welcome further dialogue on these or other topics.
Regards,
... kurt
Peter Eisentrau
(Re-sending just the fourth of four patches: c++exception)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
4. c++exception
When C code calls C++ code, all
(Re-sending just the third of four patches: c++configure)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
3. c++configure
This patch adds C++ support to t
(Re-sending just the second of four patches: c++bookends)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
2. c++bookends
C++ code can call C functions and
(Re-sending just the first of four patches: c++reserved)
These patches are based on CVS head in which the latest commit was
user:petere
date:Thu Dec 04 17:51:28 2008 +
summary: Default values for function arguments
1. c++reserved
User-defined functions and extensi
Hi Greg,
Actually I did email this to the list with 4 separate diffs in
4 separate attached files. I don't know why it appears all
massed together at http://archives.postgresql.org/pgsql-hackers.
I'll try resubmitting them separately. The first diff consists
of just the renaming, which is inten
Hi,
Brendan Jurd submitted a patch to add a pg_typeof() builtin function:
http://archives.postgresql.org/pgsql-patches/2008-09/msg00029.php
I've reviewed the patch and it looks fine. An updated version is
attached, having made these changes:
1) Rebased to current CVS head
2) func.sgml: cla
Just noticed buffile.c:292 doesn't look quite right where
BufFileDumpBuffer calls FileWrite:
bytestowrite = FileWrite(thisfile, file->buffer, bytestowrite);
It looks as though it would write the same data each time the
loop is iterated. Would this be better?
bytestowrite = FileWrite(thisf
33 matches
Mail list logo