; A better option is to implement some optimized fixed precision classes like
> SQLDecimal38 and SQLDecimal65 + a more general variable precision SQLDecimal.
> But, as I mentioned, this is something different than Decimal.
>
>
> Greetings
> Raffaello
>
>
>
> On 2021-0
Understood. The problem is that right now the only appropriate type for
non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of
users avoid it.
Decimal128 supports 34 significant digits. The max precision of SQL numeric
types varies from vendor to vendor. In SQL Server it
aurizio Cimadamore
> wrote:
>
>
> On 31/03/2021 15:23, Douglas Surber wrote:
>> Rather than waiting on Valhala I would prefer that this project be fast
>> tracked and added to OpenJDK ASAP.
>
> There is a catch here.
>
> While in principle, we can add these as v
+1
JDBC would support this immediately. All it would take is the addition of a
couple of lines in some appendices to require that conforming implementations
of getObject(int, Class), setObject(int, Object, SQLType), etc support
Decimal64 and Decimal128. No change to the API required. Driver ven
> Are there current hex formatting in code you are aware of that already uses
> prefixes or suffixes on each byte?
>
Java. My example.
> { 0x00, 0x01, 0x02, 0xOD, 0x0E, 0x0F }
Douglas
> On Sep 3, 2020, at 2:24 PM, core-libs-dev-requ...@openjdk.java.net wrote:
>
> Date: Thu, 3 Sep 2020
I still want to know how to format a byte sequence where each byte has a prefix
(or suffix).
Eg.
{ 0x00, 0x01, 0x02, 0xOD, 0x0E, 0x0F }
Douglas
> On Sep 2, 2020, at 2:26 PM, core-libs-dev-requ...@openjdk.java.net wrote:
>
> Date: Wed, 2 Sep 2020 16:26:07 -0400
> From: Roger Riggs mail
The meaning of prefix and suffix is not specified in formatter​(boolean
uppercase, String delimiter,String prefix, String suffix). It isn't specified
whether they precede and follow the entire formatted value or each byte. The
class comment clarifies but I shouldn't have to go there to discover
I wrote the following simple test case to look at the uniformity of the
distribution. I don't see any problem running it up to 4096 buckets. Admittedly
I did not do any statistical tests on the buckets but by eye they look
uniformly distributed.
public static void main(String[] args) throws
java.text.SimpleDateFormat.parse does not recognize time zone ids.
new SimpleDateFormat("-MM-dd HH:mm:ss
").parse("2015-03-03 09:25:00 America/Los_Angeles")
does not recognize "America/Los_Angeles" as a time zone.
"America/Los_Angeles" is a time zone id and the "" format looks
imits" might be different than yours. As far
as I'm concerned String construction is already too slow and should
be made faster by eliminating the char[] copy when possible.
Douglas
At 03:47 PM 12/2/2014, Aleksey Shipilev wrote:
Hi Douglas,
On 12/03/2014 02:24 AM, Douglas Surber wrote:
&
String construction is a big performance issue for JDBC drivers. Most
queries return some number of Strings. The overwhelming majority of
those Strings will be short lived. The cost of constructing these
Strings from network bytes is a large fraction of total execution
time. Any increase in the
11 matches
Mail list logo
