on't understand is why when the
value gets mapped back to Java via JDBC those extra digits are coming back. Can
anyone explain this or do you think I'm on the wrong track? I stepped through
code and it sure seems like the extra information is coming back from the JDBC
driver.
Tom
--
Tom
On Feb 24, 2013, at 8:44 PM, Adrian Klaver wrote:
> On 02/24/2013 06:13 PM, Tom Duffey wrote:
>> Hi Everyone,
>>
>> Riddle me this. I have a database column of type "real" that gets mapped to
>> a Java field of type double via JDBC. We have two databases,
en using JDBC to retrieve values into a Java double
field.
I ran the above on PostgreSQL 9.1.2 and 9.2.2 with the same results.
Tom
On Feb 24, 2013, at 9:17 PM, Adrian Klaver wrote:
> On 02/24/2013 06:58 PM, Tom Duffey wrote:
>>
>> On Feb 24, 2013, at 8:44 PM, Adrian Klaver wr
when
transferring the data.
Thanks for the explanation.
Tom
On Feb 25, 2013, at 8:00 AM, Albe Laurenz wrote:
> Tom Duffey wrote:
>> Here is a smaller test case that does not involve Java. I guess this
>> probably is just due to floating
>> point error when the initial val
2013, at 7:05 PM, James Cloos wrote:
>>>>>> "TD" == Tom Duffey writes:
>
> TD> Riddle me this. I have a database column of type "real" that gets
> TD> mapped to a Java field of type double via JDBC. ...
>
> TD> - Selecting values fro
>
>>> We would get a whole lot more bug reports, not fewer, if that were
>>> the default behavior.
>
>> Isn't this a client rendering issue, rather than an on-the-wire encoding
>> issue?
>
> Nope, at least not unless you ask for binary output forma
re" and start to get worried.
Tom
--
Tom Duffey
Technology by Design :: http://techbydesign.com/
p: 414.431.0800
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Sep 21, 2009, at 12:40 PM, Scott Marlowe wrote:
On Mon, Sep 21, 2009 at 11:09 AM, Tom Duffey
wrote:
Hi All,
We're having numerous problems with a PostgreSQL 8.3.7 database
running on a
virtual Linux server w/VMWare ESX. This is not by choice and I
have been
asking the operat
Hi Everyone,
I have a table with several hundred million rows of timestamped
values. Using pg_dump we are able to dump the entire table to disk no
problem. However, I would like to retrieve a large subset of data
from this table using something like:
COPY (SELECT * FROM history WHERE ti
On May 15, 2010, at 4:51 PM, Tom Lane wrote:
Tom Duffey writes:
I have a table with several hundred million rows of timestamped
values. Using pg_dump we are able to dump the entire table to disk
no
problem. However, I would like to retrieve a large subset of data
from this table using
On May 15, 2010, at 7:28 PM, Tom Lane wrote:
Tom Duffey writes:
On May 15, 2010, at 4:51 PM, Tom Lane wrote:
What's being done on the client side with the data?
I am executing the query in psql at the command line and piping the
result to a file, e.g.,
psql < get_data.sql &g
On May 15, 2010, at 8:00 PM, Tom Lane wrote:
Tom Duffey writes:
On May 15, 2010, at 7:28 PM, Tom Lane wrote:
Well, I tried executing a large "copy (select ...)" query and
couldn't
see any memory bloat at all in either the backend or psql. So
there's
something relev
base
from a backup, which I'm still working on now. I'm wondering if
anyone has any thoughts or ideas about this? I found references to
similar problems but they were all for older versions of PostgreSQL.
When the problem occurred we were running 8.3.6 and are now running
8.3.7.
To
Hi Tom,
On Mar 25, 2009, at 9:02 PM, Tom Lane wrote:
Tom Duffey writes:
One of our databases suffered a problem yesterday during a normal
update, something we have been doing for years. Near the end of the
process a foreign key constraint is rebuilt on a table containing
several hundred
14 matches
Mail list logo
