Re: should we add a XLogRecPtr/LSN SQL type?
От | Robert Haas |
---|---|
Тема | Re: should we add a XLogRecPtr/LSN SQL type? |
Дата | |
Msg-id | CA+TgmobPja=vvqNNUUQM6HwsKi1uTAo1Hxixd8J4wzgJafsYtg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: should we add a XLogRecPtr/LSN SQL type? (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: should we add a XLogRecPtr/LSN SQL type?
|
Список | 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 по дате отправления: