Peter Eisentraut writes:
> I have never used the money type, so I'm not in a position to argue what
> might be typical use cases, but it is well understood that using
> floating-point arithmetic anywhere in calculations involving money is
> prohibited by law or business rules in most places. So w
On lör, 2010-07-17 at 10:00 -0500, Kevin Grittner wrote:
> True. If we added money * numeric, then it would make more sense to
> have money / money return numeric. On the other hand, I couldn't
> come up with enough use cases for that to feel that it justified the
> performance hit on money / mon
On lör, 2010-07-17 at 07:20 -0700, Andy Balholm wrote:
> On Jul 17, 2010, at 3:20 AM, Peter Eisentraut wrote:
>
> > On fre, 2010-07-16 at 10:31 -0400, Tom Lane wrote:
> >> The other argument that I found convincing was that if the
> >> operator was defined to yield numeric, people might think that
Peter Eisentraut wrote:
> I read most of these messages rather as advocating the use of
> NUMERIC.
Yeah, I did advocate that at first, but became convinced float8 was
more appropriate.
> Also, the multiplication problem can be addressed by adding a
> money * numeric operator.
True. If we
Peter Eisentraut writes:
> On fre, 2010-07-16 at 10:31 -0400, Tom Lane wrote:
>> The other argument that I found convincing was that if the
>> operator was defined to yield numeric, people might think that
>> the result was exact ... which of course it won't be, either way.
>> Choosing float8 help
On Jul 17, 2010, at 3:20 AM, Peter Eisentraut wrote:
> On fre, 2010-07-16 at 10:31 -0400, Tom Lane wrote:
>> The other argument that I found convincing was that if the
>> operator was defined to yield numeric, people might think that
>> the result was exact ... which of course it won't be, either
On fre, 2010-07-16 at 10:31 -0400, Tom Lane wrote:
> The other argument that I found convincing was that if the
> operator was defined to yield numeric, people might think that
> the result was exact ... which of course it won't be, either way.
> Choosing float8 helps to remind the user it's an app
On fre, 2010-07-16 at 08:55 -0500, Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
> > I didn't see any discussion about why this should return float8
> > rather than numeric. It seems wrong to use float8 for this.
>
> That discussion took place several months ago on the -bugs list.
> I'll
On fre, 2010-07-16 at 12:21 -0400, Tom Lane wrote:
> Actually ... the thing that might turn money into a less deprecated
> type
> is if you could set lc_monetary per column. I wonder whether Peter's
> collation hack could be extended to deal with that.
In principle yes.
--
Sent via pgsql-hack
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The only way I'd be willing to label those things immutable was if
>> we did something to lock down lc_monetary for the life of a
>> database (ie, make it work more like lc_collate does now). Which
>> might be a good idea, but it's not how it works t
Tom Lane wrote:
> The only way I'd be willing to label those things immutable was if
> we did something to lock down lc_monetary for the life of a
> database (ie, make it work more like lc_collate does now). Which
> might be a good idea, but it's not how it works today.
Interesting. In gener
"Kevin Grittner" writes:
> Tom Lane wrote:
>> * The cast functions were marked immutable, which is wrong because
>> they depend on the setting of lc_monetary. The right marking is
>> "stable".
> Is there any impact of the change to lc_monetary which would matter
> besides the number of decimal
Andy Balholm writes:
> On Jul 15, 2010, at 7:25 PM, Tom Lane wrote:
>> * I didn't like this bit in cash_numeric():
>>
>> result->n_sign_dscale = NUMERIC_SIGN(result) | fpoint;
>>
>> Not only is that unwarranted chumminess with the implementation of
>> numeric, it's flat-out wrong. If the result
"Kevin Grittner" writes:
> Peter Eisentraut wrote:
>> I didn't see any discussion about why this should return float8
>> rather than numeric. It seems wrong to use float8 for this.
> That discussion took place several months ago on the -bugs list.
> I'll paste some links from a quick search o
On Jul 15, 2010, at 7:25 PM, Tom Lane wrote:
> * I didn't like this bit in cash_numeric():
>
> result->n_sign_dscale = NUMERIC_SIGN(result) | fpoint;
>
> Not only is that unwarranted chumminess with the implementation of
> numeric, it's flat-out wrong. If the result isn't exactly the righ
Peter Eisentraut wrote:
> I didn't see any discussion about why this should return float8
> rather than numeric. It seems wrong to use float8 for this.
That discussion took place several months ago on the -bugs list.
I'll paste some links from a quick search of the archives below.
Since mul
Tom Lane wrote:
> * I didn't like this bit in cash_numeric():
>
> result->n_sign_dscale = NUMERIC_SIGN(result) | fpoint;
>
> Not only is that unwarranted chumminess with the implementation of
> numeric, it's flat-out wrong. If the result isn't exactly the
> right number of digits (say,
On tor, 2010-07-15 at 22:25 -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Andy Balholm wrote:
> >> On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote:
> >> I deleted the excess comments and moved some lines around. Here it
> >> is with the changes.
>
> > I ran pgindent to standardize th
"Kevin Grittner" writes:
> Andy Balholm wrote:
>> On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote:
>> I deleted the excess comments and moved some lines around. Here it
>> is with the changes.
> I ran pgindent to standardize the white space. (No changes of
> substance.) Patch attached.
>
Andy Balholm wrote:
> On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote:
>> The only issue is with the general guideline to make the new code
>> blend in with existing code:
> I deleted the excess comments and moved some lines around. Here it
> is with the changes.
I ran pgindent to standar
On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote:
> Yes, although the line endings are Windows format (CR/LF).
The line endings must have gotten changed in transit. My original diff used
just LF. I made it on a Mac.
> The only issue is with the general guideline to make the new code
> blend
Andy Balholm wrote:
> On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
>> You would then generate a diff in context format and post to the
>> -hackers list with that file as an attachment.
>
> Here it is
=
Submission review
=
* Is the patch in context diff
Alvaro Herrera wrote:
> Hmm, cvs diff -Ncp does show method names too, so this is probably
> filterdiff removing them.
My bad; I apparently got confused somehow when looking at a context
diff -- the function names are indeed there after the filterdiff
conversion. Sorry for the noise on that.
Excerpts from Kevin Grittner's message of mar jun 01 11:09:38 -0400 2010:
> I agree about the git diff being easier; however, those files are in
> unified format and some committers prefer to read the context
> format, so I'd recommend piping it through filterdiff
> --format=context. Personally,
Andy Balholm wrote:
> I made my diff with src/tools/make_diff, as suggested in the
> Developer FAQ. But using git diff would be less hassle. Do the
> diffs from git diff work just as well?
I agree about the git diff being easier; however, those files are in
unified format and some committers p
Andy Balholm wrote:
Thanks for the explanation of CommitFests.
On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
You would then generate a diff in context format and post to the
-hackers list with that file as an attachment.
I made my diff with src/tools/make_diff, as suggested in the Dev
Andy Balholm wrote:
> Thanks for the explanation of CommitFests.
>
> >> On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
> >>> You would then generate a diff in context format and post to the
> >>> -hackers list with that file as an attachment.
>
> I made my diff with src/tools/make_diff, as su
Thanks for the explanation of CommitFests.
>> On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
>>> You would then generate a diff in context format and post to the
>>> -hackers list with that file as an attachment.
I made my diff with src/tools/make_diff, as suggested in the Developer FAQ. Bu
Andy Balholm wrote:
> On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
>> You would then generate a diff in context format and post to the
>> -hackers list with that file as an attachment.
>
> Here it is:
>
> [context diff attachment]
>
> I can't add it to the CommitFest page, since I don't
On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
> You would then generate a diff in context format and post to the
> -hackers list with that file as an attachment.
Here it is:
dividing-money.diff
Description: Binary data
> Don't forget to add
> it to the "CommitFest" page:
>
> https://comm
Andy Balholm writes:
> How do I come up with OID numbers for my new operators and functions?
Go into src/include/catalog and run the "unused_oids" script found
there. Pick some.
Your chances of getting numbers close to those currently in use for
money-related functions are probably nil, so I'd
On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
> You would basically move the functions and their prototypes to cash.c
> and cash.h, and then (instead of CREATE FUNCTION, etc.) add
> corresponding entries to pg_proc.h and pg_operator.h. (If I'm
> missing something, someone please jump in.) Of
Andy Balholm wrote:
On May 26, 2010, at 11:18 AM, Kevin Grittner wrote:
>> Do you want to package this up as a patch for 9.1? If not, is it
>> OK if I do?
> I'm not quite sure how to go about changing it from an add-on
> function to a built-in one. So if you want to do that, go ahead. If
> you'
33 matches
Mail list logo
