?
Nope, at least not unless you ask for binary output format (which
introduces a whole different set of portability gotchas, so it's
not the default either).
regards, tom lane
--
Tom Duffey
tduf...@trillitech.com
414-751-0600 x102
--
Sent via pgsql-general mailing list
PM, James Cloos cl...@jhcloos.com wrote:
TD == Tom Duffey tduf...@trillitech.com 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 from both test and production DBs using psql
TD shows
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 adrian.kla...@gmail.com wrote:
On 02/24/2013 06:58 PM, Tom Duffey wrote:
On Feb 24, 2013, at 8:44 PM, Adrian Klaver adrian.kla...@gmail.com wrote
transferring the data.
Thanks for the explanation.
Tom
On Feb 25, 2013, at 8:00 AM, Albe Laurenz laurenz.a...@wien.gv.at 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 value
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 Duffey
tduf...@trillitech.com
414-751-0600 x102
--
Sent via pgsql
On Feb 24, 2013, at 8:44 PM, Adrian Klaver adrian.kla...@gmail.com 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, test and
production
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
On May 15, 2010, at 4:51 PM, Tom Lane wrote:
Tom Duffey tduf...@trillitech.com 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
On May 15, 2010, at 7:28 PM, Tom Lane wrote:
Tom Duffey tduf...@trillitech.com 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
On May 15, 2010, at 8:00 PM, Tom Lane wrote:
Tom Duffey tduf...@trillitech.com 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
an NFS share. VMWare sees that
share and reads the VMDK file that make up the virtual file system.
Does anyone with a better understanding of PostgreSQL and VMWare know
if this is an unreliable setup for PostgreSQL? I see things like
NFS and VMWare and start to get worried.
Tom
--
Tom
On Sep 21, 2009, at 12:40 PM, Scott Marlowe wrote:
On Mon, Sep 21, 2009 at 11:09 AM, Tom Duffey
tduf...@techbydesign.com 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
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.
Tom
--
Tom Duffey tduf...@techbydesign.com
Technology by Design :: http
Hi Tom,
On Mar 25, 2009, at 9:02 PM, Tom Lane wrote:
Tom Duffey tduf...@techbydesign.com 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
14 matches
Mail list logo
