On Mon, Dec 05, 2005 at 08:24:16AM -0500, John D. Burger wrote:
> >>There are practical applications, eg, 1024-bit keys are fairly common
> >>objects in cryptography these days, and that equates to about 10^308.
> >>I don't really foresee anyone trying to run crypto algorithms with SQL
> >>NUMERIC
There are practical applications, eg, 1024-bit keys are fairly common
objects in cryptography these days, and that equates to about 10^308.
I don't really foresee anyone trying to run crypto algorithms with SQL
NUMERIC arithmetic, though ...
2046 bit keys are becoming more common. However, math
On Sat, Dec 03, 2005 at 11:43:00 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Martijn van Oosterhout writes:
> > On Fri, Dec 02, 2005 at 07:37:49PM -0500, Tom Lane wrote:
> >> So the product I fancifully mentioned would weigh in somewhere around
> >> 10^300, and thus be *well* within the capabil
Martijn van Oosterhout writes:
> On Fri, Dec 02, 2005 at 07:37:49PM -0500, Tom Lane wrote:
>> So the product I fancifully mentioned would weigh in somewhere around
>> 10^300, and thus be *well* within the capability of even the proposed
>> restricted numeric format.
> I think numbers much bigger
On Fri, Dec 02, 2005 at 07:37:49PM -0500, Tom Lane wrote:
> So the product I fancifully mentioned would weigh in somewhere around
> 10^300, and thus be *well* within the capability of even the proposed
> restricted numeric format.
I think numbers much bigger than that are only useful for theoretic
I wrote:
> The actual effective limit on NUMERIC is presently 10^128K, which is
> probably enough to count the femtoseconds remaining until the heat death
> of the universe, and then multiply that by the number of elementary
> particles therein ;-).
Should have done my research first. A little go
"Roger Hand" <[EMAIL PROTECTED]> writes:
> I would be in favor of this change. What's the plan for anyone who
> may be currently using > 508 digits (if there is anyone!)?
You could store your data as text columns and do whatever arithmetic
you had in mind on the client side.
Bruce Momjian writes:
> There is a patch under consideration for 8.2 that would reduce the
> storage requirement for numeric values by two bytes, but also reduce the
> range of allowed numeric values to 508 digits. The current specified
> maximum NUMERIC length is 1000 (NUMERIC(1000,0)), and the
Bruce Momjian
Sent: Friday, December 02, 2005 9:39 AM
>
> There is a patch under consideration for 8.2 that would reduce the
> storage requirement for numeric values by two bytes, but also reduce the
> range of allowed numeric values to 508 digits.
...
> Is that an acceptable tradeoff (reduced s
