Re: [GENERAL]
| От | Rhhh Lin |
|---|---|
| Тема | Re: [GENERAL] |
| Дата | |
| Msg-id | DB6PR1001MB114161C36608B56AAA57027EAE520@DB6PR1001MB1141.EURPRD10.PROD.OUTLOOK.COM обсуждение исходный текст |
| Ответ на | [GENERAL] ("K. Brannen" <kbrannen@pwhome.com>) |
| Список | pgsql-general |
Thanks for the explanation Kevin!
Regards,
Ruan
From: pgsql-general-owner@postgresql.org <pgsql-general-owner@postgresql.org> on behalf of K. Brannen <kbrannen@pwhome.com>
Sent: 03 November 2017 14:35
To: pgsql-general@postgresql.org
Subject: [GENERAL]
Sent: 03 November 2017 14:35
To: pgsql-general@postgresql.org
Subject: [GENERAL]
Rhhh Lin <ruanlinehan@hotmail.com> wrote:
> *Also, as a sidenote - can someone please expand on why one (I was not involved in the creation of this DB/schema definition) would choose to have the definition of the timestamp column as a bigint in this case?
Because the time value you need to hold exceeds 32 bits. :)
Based on your example, you're storing epoch in milliseconds, which exceeds 2^32, so you have to use bigint. Check out the size of the int and bigint data types in the docs.
HTH,
Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> *Also, as a sidenote - can someone please expand on why one (I was not involved in the creation of this DB/schema definition) would choose to have the definition of the timestamp column as a bigint in this case?
Because the time value you need to hold exceeds 32 bits. :)
Based on your example, you're storing epoch in milliseconds, which exceeds 2^32, so you have to use bigint. Check out the size of the int and bigint data types in the docs.
HTH,
Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: