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