On 3/21/17 18:52, Mark Dilger wrote:
> The patch applies cleanly, compiles, and passes all the regression tests
> for me on my laptop. Peter appears to have renamed the function copyObject
> as copyObjectImpl, which struct me as odd when I first saw it, but I don't
> have
> a better name in mind,
On 3/21/17 6:52 PM, Mark Dilger wrote:
On Mar 21, 2017, at 2:13 PM, David Steele wrote:
Hi Mark,
On 3/9/17 3:34 PM, Peter Eisentraut wrote:
On 3/7/17 18:27, Mark Dilger wrote:
You appear to be using a #define macro to wrap a function of the same name
with the code:
#define copyObject(obj)
> On Mar 21, 2017, at 2:13 PM, David Steele wrote:
>
> Hi Mark,
>
> On 3/9/17 3:34 PM, Peter Eisentraut wrote:
>> On 3/7/17 18:27, Mark Dilger wrote:
>>> You appear to be using a #define macro to wrap a function of the same name
>>> with the code:
>>>
>>> #define copyObject(obj) ((typeof(obj))
Hi Mark,
On 3/9/17 3:34 PM, Peter Eisentraut wrote:
On 3/7/17 18:27, Mark Dilger wrote:
You appear to be using a #define macro to wrap a function of the same name
with the code:
#define copyObject(obj) ((typeof(obj)) copyObject(obj))
Yeah, that's a bit silly. Here is an updated version that
On 3/7/17 18:27, Mark Dilger wrote:
> You appear to be using a #define macro to wrap a function of the same name
> with the code:
>
> #define copyObject(obj) ((typeof(obj)) copyObject(obj))
Yeah, that's a bit silly. Here is an updated version that changes that.
--
Peter Eisentraut
Mark Dilger writes:
> You appear to be using a #define macro to wrap a function of the same name
> with the code:
> #define copyObject(obj) ((typeof(obj)) copyObject(obj))
> I don't necessarily have a problem with that, but it struck me as a bit odd,
> and
> grep'ing through the sources, I don'
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi Peter,
I like the patch so far, and it passes all the regression test
On 12/31/16 11:56 AM, Tom Lane wrote:
> But doesn't this result in a boatload of warnings on compilers that
> don't have typeof()?
> Also, if your answer is "you shouldn't get any warnings because
> copyObject is already declared to return void *", then why aren't
> we just relying on that today?
Peter Eisentraut writes:
> In order to reduce the number of useless casts and make the useful casts
> more interesting, here is a patch that automatically casts the result of
> copyNode() back to the input type, if the compiler supports something
> like typeof(), which most current compilers appea
In order to reduce the number of useless casts and make the useful casts
more interesting, here is a patch that automatically casts the result of
copyNode() back to the input type, if the compiler supports something
like typeof(), which most current compilers appear to. That gets us
some more type
10 matches
Mail list logo
