Re: pgsql: Further code review for pg_lsn data type.
От | Heikki Linnakangas |
---|---|
Тема | Re: pgsql: Further code review for pg_lsn data type. |
Дата | |
Msg-id | 53059FBD.7080408@vmware.com обсуждение исходный текст |
Ответ на | Re: pgsql: Further code review for pg_lsn data type. (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: pgsql: Further code review for pg_lsn data type.
|
Список | 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 по дате отправления: