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
the
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 / money
Peter Eisentraut pete...@gmx.net 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
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-hackers
On fre, 2010-07-16 at 08:55 -0500, Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net 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.
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
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 way.
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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.
Tom Lane t...@sss.pgh.pa.us 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
Peter Eisentraut pete...@gmx.net 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
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 right
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Peter Eisentraut pete...@gmx.net 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
Andy Balholm a...@balholm.com 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us 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.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Andy Balholm a...@balholm.com 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
On tor, 2010-07-15 at 22:25 -0400, Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Andy Balholm a...@balholm.com 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
Andy Balholm a...@balholm.com 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
Andy Balholm a...@balholm.com 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
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 a...@balholm.com 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
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. But
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
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
Andy Balholm a...@balholm.com 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
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,
Alvaro Herrera alvhe...@commandprompt.com 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.
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:
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'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 a...@balholm.com 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
33 matches
Mail list logo
