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?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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?
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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
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...
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/