Обсуждение: pg_lsn cast to/from int8
Is there a reason we don't have casts between int8 and pg_lsn? AFAICT it works fine if I create the cast manually... Is it because of signed/unsigned if people have really really many transactions?
--
On 2016-01-26 14:56:21 +0100, Magnus Hagander wrote: > Is there a reason we don't have casts between int8 and pg_lsn? AFAICT it > works fine if I create the cast manually... Is it because of > signed/unsigned if people have really really many transactions? What for do you want that cast? Yes, the internally mostly share the representation, but other than that, I don't really see why it's interesting?
On Tue, Jan 26, 2016 at 3:00 PM, Andres Freund <andres@anarazel.de> wrote:
On 2016-01-26 14:56:21 +0100, Magnus Hagander wrote:
> Is there a reason we don't have casts between int8 and pg_lsn? AFAICT it
> works fine if I create the cast manually... Is it because of
> signed/unsigned if people have really really many transactions?
What for do you want that cast? Yes, the internally mostly share the
representation, but other than that, I don't really see why it's
interesting?
On 26 January 2016 at 22:07, Magnus Hagander <magnus@hagander.net> wrote:
In this case, mostly legacy compatibility. Making an app that works with versions that don't have pg_lsn have a nice path forward to the modern world. Being able to cast from pg_lsn to int8 can also make it easier to work with the values in the client application, though I don't need that for this particular one.
Wouldn't we need a uint8 type for that?
I guess we could just show people negative LSNs if the high bit is set (that being rather unlikely) but still...
On Tue, Jan 26, 2016 at 4:58 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 26 January 2016 at 22:07, Magnus Hagander <magnus@hagander.net> wrote:In this case, mostly legacy compatibility. Making an app that works with versions that don't have pg_lsn have a nice path forward to the modern world. Being able to cast from pg_lsn to int8 can also make it easier to work with the values in the client application, though I don't need that for this particular one.Wouldn't we need a uint8 type for that?I guess we could just show people negative LSNs if the high bit is set (that being rather unlikely) but still...
Yes, in theory. Though the likelihood of actually reaching that... It would probably be OK to just throw an error if the high bit is actually set.