On 29/03/13 12:39, Jasen Betts wrote:
On 2013-03-28, Gavin Flower gavinflo...@archidevsys.co.nz wrote:
Hmm... This should optionally apply to time. e.g.
time_i_got_up_in_the_morning should reflect the time zone where I got up
- if I got up at 8am NZ time then this should be displayed, not 12pm
On 30/03/13 04:08, Gavan Schneider wrote:
Some thoughts.
The current MONEY type might be considered akin to ASCII. Perfect for
a base US centric accounting system where there are cents and dollars
and no need to carry smaller fractions. As discussed, there are some
details that could be
On 30/03/13 11:30, Gavan Schneider wrote:
On 29/3/13 at 3:32 AM, D'Arcy J.M. Cain wrote:
On Fri, 29 Mar 2013 11:46:40 -0400 Tom Lane wrote:
Well, this has been discussed before, and the majority view every
time has been that MONEY is a legacy thing that most people would
rather rip out than
On 30/03/13 08:36, Michael Nolan wrote:
On 3/27/13, Steve Crawford scrawf...@pinpointresearch.com wrote:
Somewhat more worrisome is the fact that it automatically rounds input
(away from zero) to fit.
select '123.456789'::money;
money
-
$123.46
So does casting to an integer:
On 4/2/2013 12:50 AM, Gavin Flower wrote:
In the bad old days when I was a COBOL programmer we always stored
money in the COBOL equivalent of an integer (numeric without a
fractional part) to avoid round off, but we displayed with a decimal
point to digits to the left. So storing as an integer
On 03/04/13 07:16, John R Pierce wrote:
On 4/2/2013 12:50 AM, Gavin Flower wrote:
In the bad old days when I was a COBOL programmer we always stored
money in the COBOL equivalent of an integer (numeric without a
fractional part) to avoid round off, but we displayed with a decimal
point to
On Sat, 2013-03-30 at 09:52 -0400, D'Arcy J.M. Cain wrote:
That's why I suggested that operations between money(2) and money(3)
should raise an error. Treat them as distinct types.
I don't think typmod is currently powerful enough to do that. It's lost
in many different types of expressions.
On 30/3/13 at 11:09 PM, D'Arcy J.M. Cain wrote:
I am formulating Cain's Law. Something like If a discussion lasts
long enough, someone will mention Godwin's Law.
+1
More formally:
As an online discussion grows longer, the probability of
Godwin's Law
being mentioned approaches one.
On 30/3/13 at 12:58 AM, D'Arcy J.M. Cain wrote:
On Sat, 30 Mar 2013 12:04:21 +1100 Gavan Schneider wrote:
No MONEY column would be complete without the ability to
specify whether it is normally DEBIT or CREDIT (or in my
preferred case
That seems extreme. What use case would there ever be
On 31/03/13 21:57, Gavan Schneider wrote:
On 30/3/13 at 12:58 AM, D'Arcy J.M. Cain wrote:
Basically if MONEY is to be a useful tool it should really handle money
matters in a way that makes accountants happy. If it can't do that then
nobody is going to bother using it for serious work since
unsubscribe
On Sun, Mar 31, 2013 at 3:31 AM, Gavan Schneider pg-...@snkmail.com wrote:
On 30/3/13 at 11:09 PM, D'Arcy J.M. Cain wrote:
I am formulating Cain's Law. Something like If a discussion lasts
long enough, someone will mention Godwin's Law.
+1
More formally:
As an online
On 31/03/2013 17:45, ajmcello wrote:
unsubscribe
Hi there,
Instructions for unsubscribing are in the footer of every email sent
from the list:
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
mailto:pgsql-general@postgresql.org)
To make changes to your
Søndag 31. mars 2013 18.45.10 skrev ajmcello :
unsubscribe
On Sun, Mar 31, 2013 at 3:31 AM, Gavan Schneider pg-...@snkmail.com wrote:
On 30/3/13 at 11:09 PM, D'Arcy J.M. Cain wrote:
I am formulating Cain's Law. Something like If a discussion lasts
long enough, someone will mention
/2013 12:59
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Money casting too liberal?
On 30/3/13 at 12:58 AM, D'Arcy J.M. Cain wrote:
On Sat, 30 Mar 2013 12:04:21 +1100 Gavan Schneider wrote:
No MONEY column would be complete without the ability to
specify whether it is normally DEBIT
On 31/3/13 at 5:20 AM, D'Arcy J.M. Cain wrote:
On Sun, 31 Mar 2013 21:57:49 +1100 Gavan Schneider wrote:
On 30/3/13 at 12:58 AM, D'Arcy J.M. Cain wrote:
That seems extreme. What use case would there ever be for making a
column always debit or always credit? I have a G/L system and most
On 29/03/13 23:32, Gavan Schneider wrote:
Some people wrote:
... Hmm... This should optionally apply to time.
... for anything that really matters, I'll work with UTC.
Is there a Godwin's law http://en.wikipedia.org/wiki/Godwin's_law
equivalent for when our conversations end up with
Interesting discussion.
The comparisons with timezones ends when it comes to exchange rates.
The rate at the time of transaction has to the stored (somewhere)
associated with the base value. Timezones are rather fixed.
+1
No way can be solved just by type
On Saturday, March 30, 2013,
On Fri, 29 Mar 2013 23:32:20 +1100
Gavan Schneider pg-...@snkmail.com wrote:
Is there a Godwin's law
I am formulating Cain's Law. Something like If a discussion lasts
long enough, someone will mention Godwin's Law.
:-)
--
D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves
On Sat, 30 Mar 2013 20:36:22 +1100
Julian temp...@internode.on.net wrote:
The comparisons with timezones ends when it comes to exchange rates.
The only comparison I made with time and time zones was in how the
column type can be refined when it is created.
With a current WIP. I'm starting to
On Fri, 29 Mar 2013 17:23:50 -0700
Jeff Davis pg...@j-davis.com wrote:
Why not have various rounding functions that do exactly what you want?
Then you can use them anywhere you want in an expression.
Perhaps but the languages that we use all have the capability to manage
this and we will
On Sat, 30 Mar 2013 12:04:21 +1100
Gavan Schneider pg-...@snkmail.com wrote:
No MONEY column would be complete without the ability to specify
whether it is normally DEBIT or CREDIT (or in my preferred case
That seems extreme. What use case would there ever be for making a
column always debit
On 2013-03-29, Gavan Schneider pg-...@snkmail.com wrote:
Some thoughts.
The current MONEY type might be considered akin to ASCII.
Perfect for a base US centric accounting system where there are
cents and dollars and no need to carry smaller fractions. As
discussed, there are some details
Martijn van Oosterhout developed tagged types back in 2005, looks like
it went nowhere. You can search for it, it was pretty interesting.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-general mailing
unsubscribe
On Wed, Mar 27, 2013 at 3:12 PM, Steve Crawford
scrawf...@pinpointresearch.com wrote:
In contrast to certain other open-source databases, PostgreSQL leans
toward protecting data from surprises and erroneous input, i.e. rejecting a
date of 2013-02-31 instead of arbitrarily
Some people wrote:
... Hmm... This should optionally apply to time.
... for anything that really matters, I'll work with UTC.
Is there a Godwin's law
http://en.wikipedia.org/wiki/Godwin's_law equivalent for when
our conversations end up with timezones getting mentioned? :)
Regards
Gavan
Some thoughts.
The current MONEY type might be considered akin to ASCII.
Perfect for a base US centric accounting system where there are
cents and dollars and no need to carry smaller fractions. As
discussed, there are some details that could be refined.
When it comes to this type being
Gavan Schneider pg-...@snkmail.com writes:
Therefore the discussion is really about the desired role for
the MONEY type. Should it be refined in its current dallar and
cents mode? or, be promoted to a more universal role (akin to a
shift from ASCII to UTF)?
Well, this has been discussed
On Fri, 29 Mar 2013 11:46:40 -0400
Tom Lane t...@sss.pgh.pa.us wrote:
Well, this has been discussed before, and the majority view every
time has been that MONEY is a legacy thing that most people would
rather rip out than sink a large amount of additional effort into.
It has some use-cases but
On 28 March 2013 13:52, Shaun Thomas stho...@optionshouse.com wrote:
On 03/28/2013 07:43 AM, Gavan Schneider wrote:
Personally I have ignored the money type in favour of numeric. Money
seemed to do too much behind the scenes for my taste, but, that's me
being lazy as well, I haven't spend
On Thu, 2013-03-28 at 23:43 +1100, Gavan Schneider wrote:
If the money type is meant to be serious then these
conventions need to be followed/settable on a column by column
basis.
I don't like the idea of tying the semantics to a column. That leaves
out values that aren't stored in a column,
On 3/27/13, Steve Crawford scrawf...@pinpointresearch.com wrote:
Somewhat more worrisome is the fact that it automatically rounds input
(away from zero) to fit.
select '123.456789'::money;
money
-
$123.46
So does casting to an integer:
select 1.25::integer
;
int4
1
On Fri, 29 Mar 2013 12:02:49 -0700
Jeff Davis pg...@j-davis.com wrote:
On Thu, 2013-03-28 at 23:43 +1100, Gavan Schneider wrote:
If the money type is meant to be serious then these
conventions need to be followed/settable on a column by column
basis.
I don't like the idea of tying the
On 29/3/13 at 3:32 AM, D'Arcy J.M. Cain wrote:
On Fri, 29 Mar 2013 11:46:40 -0400 Tom Lane wrote:
Well, this has been discussed before, and the majority view every
time has been that MONEY is a legacy thing that most people would
rather rip out than sink a large amount of additional effort
On Fri, 2013-03-29 at 16:30 -0400, D'Arcy J.M. Cain wrote:
How would this be an issue? If you are assigning a literal to a column
then that's no issue. Otherwise, a literal is simply a value that can
be cast depending on the situation. The money type is no different in
that regard.
As a
On 30/3/13 at 9:30 AM, I wrote:
I have sketched something of a notation for MONEY columns along these lines:
amt_received MONEY (CURRENCY-- e.g., 'USD' 'AUD' 'YEN' ...
[,SCALE -- default as per currency, e.g. USD 2 decimals
-- but could be used to see money in bigger units
-- such
On 27/3/13 at 9:12 AM, Steve Crawford wrote:
In contrast to certain other open-source databases, PostgreSQL leans
toward protecting data from surprises ...
And long may this continue.
But it appears that the philosophy does not extend to the money
type. ...
select
On Thu, 28 Mar 2013 23:43:23 +1100
Gavan Schneider pg-...@snkmail.com wrote:
But it appears that the philosophy does not extend to the money
type. ...
As the original author of the money type I guess I should weigh in.
select ',123,456,,7,8.1,0,9'::money;
money
On 03/28/2013 07:43 AM, Gavan Schneider wrote:
Personally I have ignored the money type in favour of numeric. Money
seemed to do too much behind the scenes for my taste, but, that's me
being lazy as well, I haven't spend much time trying to understand its
features.
You're not the only one. In
On 27/3/13 at 9:12 AM, Steve Crawford wrote:
Thoughts? Is this the no surprises way that money input should behave?
I took a quick look at cash_in(), which is what's being complained of
here (not really casting). There are several things that seem like
they could possibly stand to be tightened
On 29/03/13 02:28, D'Arcy J.M. Cain wrote:
On Thu, 28 Mar 2013 23:43:23 +1100
Gavan Schneider pg-...@snkmail.com wrote:
But it appears that the philosophy does not extend to the money
type. ...
As the original author of the money type I guess I should weigh in.
select
On 2013-03-28, D'Arcy J.M. Cain da...@druid.net wrote:
I would like to see the type handle other situations such as foreign
(to me) currency, etc. I suppose a positional parameter and a currency
string setting would handle most of those issues. Technically, the
money type is a cents type.
On 28 Mar 2013 20:50:42 GMT
Jasen Betts ja...@xnet.co.nz wrote:
it actually does that, if you have the locale installed you can set
LC_MONETARY to Japan and get no decimals and a Yen symbol
or to UAE and get three decimals and their currency symbol.
Must have been added by someone else
On 3/28/2013 2:13 PM, D'Arcy J.M. Cain wrote:
I would have rather made that part of the column definition similar to
how we create timestamps with or without timezones. If a column is
tracking Yen it should always be Yen. Y10,000 should never display as
$100.00 just because the locale changes.
On 03/28/2013 04:36 PM, John R Pierce wrote:
or to another extreme, part of the data, such that different rows could
have different monetary units.(eg, money is implemented as a pair
(currency,amount).eeek, then you'd need exchange rate tables and
such. hahahahaha, what a nightmare.
On 29/03/13 10:13, D'Arcy J.M. Cain wrote:
On 28 Mar 2013 20:50:42 GMT
Jasen Betts ja...@xnet.co.nz wrote:
it actually does that, if you have the locale installed you can set
LC_MONETARY to Japan and get no decimals and a Yen symbol
or to UAE and get three decimals and their currency symbol.
On 2013-03-28, Gavin Flower gavinflo...@archidevsys.co.nz wrote:
Hmm... This should optionally apply to time. e.g.
time_i_got_up_in_the_morning should reflect the time zone where I got up
- if I got up at 8am NZ time then this should be displayed, not 12pm (12
noon) to someone in Los
On Fri, Mar 29, 2013 at 10:39 AM, Jasen Betts ja...@xnet.co.nz wrote:
how confusing is 'EST' ?
worse than this:
set datestyle to 'sql,dmy';
set time zone 'Australia/Brisbane';
select '20130101T00Z'::timestamptz;
set time zone 'Australia/Sydney';
select '20130101T00Z'::timestamptz;
Steve Crawford wrote
select ',123,456,,7,8.1,0,9'::money;
money
$12,345,678.11
As an end-user it would seem since a comma (or whatever the locale defines
as a group separator) carries no significant information - it is purely
aesthetic - that ignoring all commas
In contrast to certain other open-source databases, PostgreSQL leans
toward protecting data from surprises and erroneous input, i.e.
rejecting a date of 2013-02-31 instead of arbitrarily assigning a date
of 2013-03-03. Similar throw error instead of take a guess
philosophy applies to numeric
49 matches
Mail list logo
