On 19/12/16 14:17, Rob Sargent wrote:
On Dec 18, 2016, at 5:23 PM, Gavin Flower wrote:
On 18/12/16 12:25, Bruce Momjian wrote:
On Wed, Nov 30, 2016 at 01:35:12PM -0800, John R Pierce wrote:
note, btw, TIMESTAMP WITH TIME ZONE doesn't actually store the timezone...
rather, it converts it to an
> On Dec 18, 2016, at 5:23 PM, Gavin Flower
> wrote:
>
> On 18/12/16 12:25, Bruce Momjian wrote:
>> On Wed, Nov 30, 2016 at 01:35:12PM -0800, John R Pierce wrote:
>>> note, btw, TIMESTAMP WITH TIME ZONE doesn't actually store the timezone...
>>> rather, it converts it to an internal representat
On 18/12/16 12:25, Bruce Momjian wrote:
On Wed, Nov 30, 2016 at 01:35:12PM -0800, John R Pierce wrote:
note, btw, TIMESTAMP WITH TIME ZONE doesn't actually store the timezone...
rather, it converts it to an internal representation of GMT, and then converts
it back to display time at the client's
On Wed, Nov 30, 2016 at 01:35:12PM -0800, John R Pierce wrote:
> note, btw, TIMESTAMP WITH TIME ZONE doesn't actually store the timezone...
> rather, it converts it to an internal representation of GMT, and then converts
> it back to display time at the client's current (or specified) time zone.
R
My two cents . . .
On Wed, 2016-11-30 at 13:35 -0800, John R Pierce wrote:
> On 11/30/2016 12:16 PM, John McKown wrote:
> > Speaking generically, I guess maybe MONEY needs to be somewhat
> > like a TIMESTAMP. At least in PostgreSQL, a TIMESTAMP can contain
> > a TIMEZONE. I guess a MONEY type shoul
On 11/30/2016 12:16 PM, John McKown wrote:
Speaking generically, I guess maybe MONEY needs to be somewhat like a
TIMESTAMP. At least in PostgreSQL, a TIMESTAMP can contain a
TIMEZONE. I guess a MONEY type should contain a modifier identifying
the issuer of the currency (E.g. U.S. Dollar vs Ca
On Wed, Nov 30, 2016 at 2:16 PM, John McKown
wrote:
> On Wed, Nov 30, 2016 at 1:23 PM, bto...@computer.org
> wrote:
> Speaking generically, I guess maybe MONEY needs to be somewhat like a
> TIMESTAMP. At least in PostgreSQL, a TIMESTAMP can contain a TIMEZONE. I
> guess a MONEY type should contai
On Wed, Nov 30, 2016 at 1:23 PM, bto...@computer.org wrote:
>
> I recall a number of years ago reading about a money implementation that
> included different currency bases and exchange rate calculation. A quick
> Google search turned up
>
>
> https://github.com/samv/pg-currency
>
>
> which I am
- Original Message -
> From: "Merlin Moncure"
> To: "Raymond O'Donnell"
> Cc: "Thomas Kellerer" , "PostgreSQL General"
>
> Sent: Wednesday, November 30, 2016 11:41:39 AM
> Subject: Re: [GENERAL] About the MONEY type
On Wed, Nov 30, 2016 at 7:43 AM, Raymond O'Donnell wrote:
> On 30/11/16 12:05, Thomas Kellerer wrote:
>>
>> Tobia Conforto schrieb am 30.11.2016 um 12:15:
>>>
>>> I think MONEY is a great datatype, at least in theory.
>>
>>
>> I personally find it pretty useless to be honest - especially because
>
On Wed, Nov 30, 2016 at 6:43 AM, Raymond O'Donnell wrote:
>
> I seem to remember that it was actually deprecated at some point - this is
> going back quite a few years. This was later reversed, though I don't know
> why.
>
>
Because its pointless to deprecate something that you haven't replaced
>> I think MONEY is a great datatype, at least in theory.
>
> I personally find it pretty useless to be honest - especially because
> the currency symbol depends on the client.
I should have been more clear: I find the underlying idea of storing a
fixed-scale decimal number as a pre-scaled int8 co
On 30/11/16 12:05, Thomas Kellerer wrote:
Tobia Conforto schrieb am 30.11.2016 um 12:15:
I think MONEY is a great datatype, at least in theory.
I personally find it pretty useless to be honest - especially because
the currency symbol depends on the client.
So if I store a money value in the d
Tobia Conforto schrieb am 30.11.2016 um 12:15:
> I think MONEY is a great datatype, at least in theory.
I personally find it pretty useless to be honest - especially because the
currency symbol depends on the client.
So if I store a money value in the database, some clients see CHF, some see Kč
I think MONEY is a great datatype, at least in theory.
It's stored as a 64 bit binary integer with an implied, fixed decimal
scale. This means that storage is conserved and operations are as fast
and exact as possible (to the implied decimal scale.)
Unfortunately it has a couple of significant dr
15 matches
Mail list logo
