Thread: Numeric data types

Greetings Listees (frist time poster!)

Considering the difference between 64 bit and 32 bit numeric datatypes. We have source databases that are running 32 bit. They send their data to a larger cluster that is running 64 bit. Should there be something special done in order to accommodate the difference?

Thanks,

Pg

Phil Godfrin | Database Administrator

NOV

NOV US | Engineering Data

9720 Beechnut St | Houston, Texas 77036

M  281.825.2311

E   Philippe.Godfrin@nov.com

The information contained in this transmission is for the personal and confidential use of the individual or entity to which it is addressed. If the reader is not the intended recipient, you are hereby notified that any review, dissemination, or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify the sender immediately.

Thanks Bruce, I suppose you mean n32 -> n64 OK, but n64->n32 chance of 32-bit overflow…

pg

On Mon, Aug 31, 2020 at 04:38:05PM +0000, Godfrin, Philippe E wrote:
> Greetings Listees (frist time poster!)
>
>
>
> Considering the difference between 64 bit and 32 bit numeric datatypes. We have
> source databases that are running 32 bit. They send their data to a larger
> cluster that is running 64 bit. Should there be something special done in order
> to accommodate the difference?

How is the data sent? In almost every case, the translation should work
fine. I think 32-bit overflow should be your only concern here.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

Fabulous, thanks much.

On Mon, Aug 31, 2020 at 05:32:23PM +0000, Godfrin, Philippe E wrote:
> Thanks Bruce, I suppose you mean n32 -> n64 OK, but n64->n32 chance of 32-bit
> overflow…

Uh, I was thinking that your 32-bit values could roll over and the other
end would be confused, but I can also see the 64-bit going above the
32-bit range. As long as everything stays < 32-bits, you should be
fine. We don't transfer binary values very often.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

Frankly, I’m not certain, I believe the developers are using a messaging intermediary.

pg

On Mon, Aug 31, 2020 at 10:14:48PM +0000, Godfrin, Philippe E wrote:
> Fabulous, thanks much.

You still have not told us how you are transfering the data, so we can
be sure.

---------------------------------------------------------------------------

>
> From: Bruce Momjian <bruce@momjian.us>
> Sent: Monday, August 31, 2020 4:56 PM
> To: Godfrin, Philippe E <Philippe.Godfrin@nov.com>
> Cc: pgsql-general@postgresql.org
> Subject: Re: [EXTERNAL] Re: Numeric data types
>
>
>
> On Mon, Aug 31, 2020 at 05:32:23PM +0000, Godfrin, Philippe E wrote:
> > Thanks Bruce, I suppose you mean n32 -> n64 OK, but n64->n32 chance of 32-bit
> > overflow…
>
> Uh, I was thinking that your 32-bit values could roll over and the other
> end would be confused, but I can also see the 64-bit going above the
> 32-bit range. As long as everything stays < 32-bits, you should be
> fine. We don't transfer binary values very often.
>
> --
> Bruce Momjian <bruce@momjian.us> https://momjian.us
> EnterpriseDB https://enterprisedb.com
>
> The usefulness of a cup is in its emptiness, Bruce Lee
>

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee

Very well, thanks very much.

pg

On Mon, Aug 31, 2020 at 10:20:51PM +0000, Godfrin, Philippe E wrote:
> Frankly, I’m not certain, I believe the developers are using a messaging
> intermediary.

Oh, well, then you would need to find out if they are transfering the
value via text or binary. It is kind of hard to extract query results
as binary, but it is technically possible with binary COPY or triggers.

---------------------------------------------------------------------------

>
> pg
>
>
>
> From: Bruce Momjian <bruce@momjian.us>
> Sent: Monday, August 31, 2020 5:19 PM
> To: Godfrin, Philippe E <Philippe.Godfrin@nov.com>
> Cc: pgsql-general@postgresql.org
> Subject: Re: [EXTERNAL] Re: Numeric data types
>
>
>
> On Mon, Aug 31, 2020 at 10:14:48PM +0000, Godfrin, Philippe E wrote:
> > Fabulous, thanks much.
>
> You still have not told us how you are transfering the data, so we can
> be sure.
>
> ---------------------------------------------------------------------------
>
> >
> > From: Bruce Momjian <bruce@momjian.us>
> > Sent: Monday, August 31, 2020 4:56 PM
> > To: Godfrin, Philippe E <Philippe.Godfrin@nov.com>
> > Cc: pgsql-general@postgresql.org
> > Subject: Re: [EXTERNAL] Re: Numeric data types
> >
> >
> >
> > On Mon, Aug 31, 2020 at 05:32:23PM +0000, Godfrin, Philippe E wrote:
> > > Thanks Bruce, I suppose you mean n32 -> n64 OK, but n64->n32 chance of
> 32-bit
> > > overflow…
> >
> > Uh, I was thinking that your 32-bit values could roll over and the other
> > end would be confused, but I can also see the 64-bit going above the
> > 32-bit range. As long as everything stays < 32-bits, you should be
> > fine. We don't transfer binary values very often.
> >
> > --
> > Bruce Momjian <bruce@momjian.us> https://momjian.us
> > EnterpriseDB https://enterprisedb.com
> >
> > The usefulness of a cup is in its emptiness, Bruce Lee
> >
>
> --
> Bruce Momjian <bruce@momjian.us> https://momjian.us
> EnterpriseDB https://enterprisedb.com
>
> The usefulness of a cup is in its emptiness, Bruce Lee
>

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee