Re: should we add a XLogRecPtr/LSN SQL type? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: should we add a XLogRecPtr/LSN SQL type?
Date
Msg-id CA+TgmobPja=vvqNNUUQM6HwsKi1uTAo1Hxixd8J4wzgJafsYtg@mail.gmail.com
Whole thread Raw
In response to Re: should we add a XLogRecPtr/LSN SQL type?  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: should we add a XLogRecPtr/LSN SQL type?
List pgsql-hackers
On Wed, Feb 19, 2014 at 9:30 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-02-19 09:24:03 -0500, Robert Haas wrote:
>> On Fri, Feb 14, 2014 at 9:32 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>> > On Thu, Feb 6, 2014 at 11:26 AM, Michael Paquier
>> > <michael.paquier@gmail.com> wrote:
>> >> Here are updated patches to use pg_lsn instead of pglsn...
>> > Should I register this patch somewhere to avoid having it lost in the void?
>> > Regards,
>>
>> Well, I committed this, but the buildfarm's deeply unhappy with it.
>> Apparently the use of GET_8_BYTES() and SET_8_BYTES() is no good on
>> some platforms...  and I'm not sure what to do about that, right
>> off-hand.
>
> The relevant bit probably is:
>
> pg_lsn.c: In function 'pg_lsn_out':
> pg_lsn.c:59:2: warning: implicit declaration of function 'GET_8_BYTES' [-Wimplicit-function-declaration]
>
> GET_8_BYTES only exists for 64bit systems.

Right, I got that far.  So it looks like float8, int8, timestamp,
timestamptz, and money all have behavior contingent on
USE_FLOAT8_BYVAL, making that symbol a misnomer in every way.  But
since we've already marched pretty far down that path I suppose we
should keep marching.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: should we add a XLogRecPtr/LSN SQL type?
Next
From: "MauMau"
Date:
Subject: Re: Do you know the reason for increased max latency due to xlog scaling?