Andres Freund writes:
> On 2017-09-30 12:17:06 -0400, Tom Lane wrote:
>> c.h will already have included . There might be some
>> value in this if we anticipated allowing freestanding use of this
>> header, but that won't happen because it depends on configure symbols.
>
On 2017-09-30 12:17:06 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Extend & revamp pg_bswap.h infrastructure.
>
> Hm, what is the point of this in pg_bswap.h:
>
> +#ifdef _MSC_VER
> +#include
> +#endif
>
> c.h will already have included . There might be some
>
Andres Freund writes:
> Extend & revamp pg_bswap.h infrastructure.
Hm, what is the point of this in pg_bswap.h:
+#ifdef _MSC_VER
+#include
+#endif
c.h will already have included . There might be some
value in this if we anticipated allowing freestanding use of this
On 2017-09-29 17:33:51 -0700, Peter Geoghegan wrote:
> On Fri, Sep 29, 2017 at 5:29 PM, Andres Freund wrote:
> > Extend & revamp pg_bswap.h infrastructure.
>
> This looks wrong:
>
> +static inline uint16
> +pg_bswap64(uint16 x)
> +{
Yea, just noticed that :(. Running test,
On Fri, Sep 29, 2017 at 5:29 PM, Andres Freund wrote:
> Extend & revamp pg_bswap.h infrastructure.
This looks wrong:
+static inline uint16
+pg_bswap64(uint16 x)
+{
+ return
+ ((x << 56) & UINT64CONST(0xff00)) |
+ ((x << 40) &
Extend & revamp pg_bswap.h infrastructure.
Upcoming patches are going to address performance issues that involve
slow system provided ntohs/htons etc. To address that expand
pg_bswap.h to provide pg_ntoh{16,32,64}, pg_hton{16,32,64} and
optimize their respective implementations by using compiler