Re: pgsql: Further code review for pg_lsn data type. - Mailing list pgsql-committers

From Heikki Linnakangas
Subject Re: pgsql: Further code review for pg_lsn data type.
Date
Msg-id 53059FBD.7080408@vmware.com
Whole thread Raw
In response to Re: pgsql: Further code review for pg_lsn data type.  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: pgsql: Further code review for pg_lsn data type.  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-committers
On 02/20/2014 02:56 AM, Andres Freund wrote:
> On 2014-02-19 15:10:52 +0000, Robert Haas wrote:
>> Change input function error messages to be more consistent with what is
>> done elsewhere.  Remove a bunch of redundant type casts, so that the
>> compiler will warn us if we screw up.  Don't pass LSNs by value on
>> platforms where a Datum is only 32 bytes, per buildfarm.  Move macros
>> for packing and unpacking LSNs to pg_lsn.h so that we can include
>> access/xlogdefs.h, to avoid an unsatisfied dependency on XLogRecPtr.
>
> Hm, won't
> #define DatumGetLSN(X) ((XLogRecPtr) DatumGetInt64(X))
> #define LSNGetDatum(X) (Int64GetDatum((int64) (X)))
> possibly truncate the value if it's larger than 2^(63-1) as int is
> signed but XLogRecPtr is unsigned?

No. Casting between unsigned and signed integers of same width doesn't
lose information. For example with 16-bit integers, casting unsigned
40000 to signed gives -25536. Casting signed -25536 back to unsigned
gives back 40000.

- Heikki


pgsql-committers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Re: pgsql: Add a GUC to report whether data page checksums are enabled.
Next
From:
Date:
Subject: ...