2011/8/4 Silvio Brandani :
> On the Tomcat side we get followin message:
>
>
> Caused by: java.io.IOException: Tried to send an out-of-range integer as a
> 2-byte value: 34027
> at org.postgresql.core.PGStream.SendInteger2(PGStream.java:201)
> at
> org.postgresql.core.v3.QueryExecutorImpl.sendPars
Saneesh Apte wrote:
I think I found two bugs (and I hope I am not wasting everyone's time).
One is minor: the base type of a boolean[] is java.sql.Types.BIT
instead or java.sql.Types.BOOLEAN. At the very least shouldn't these be
aliases for the same type?
Types.BOOLEAN does not exis
Julius Stroffek wrote:
There is only one option that comes to my mind - always return
Statment.SUCCESS_NO_INFO in executeBatch (or possibly only depending on
some java property). I can not see any simple solution for
Statement.executeUpdate since the number of rows affected may differ
dependi
Mike Clements wrote:
Insert a row into the table using:
Connection.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS);
The driver throws an exception saying this method is not yet implemented.
This is an optional part of the JDBC spec, and the driver doesn't claim
to support it in the met
Steve Peterson wrote:
> Any known way to log at the JDBC level? When I get a little time I'm
> going to write a test that bypasses Eclipse and SQLExplorer.
Pass 'logLevel=2' as a URL parameter in the JDBC URL; that will log all
protocol-level messages sent and received, including the query text.
Alvaro Herrera wrote:
> On Fri, Sep 30, 2005 at 10:37:05PM -0500, Steve Peterson wrote:
>
>>The query is submitted using the JDBC driver, via
>>the SQLExplorer plugin for Eclipse.
>>
>>Is there a way for me to see the query as it was
>>submitted to the backend? If so I'll take a look and see wh
Kevin Grittner wrote:
> I'm afraid I'm not familiar with a good way to capture the stream of
> communications with the database server. If you could point me in the right
> direction, I'll give it my best shot.
tcpdump will do the trick (something like 'tcpdump -n -w
some.output.file -s 1514 -
Bernard wrote:
Certainly supporting COPY via STDIN within the java code seems preferable.
Why do you say that? That option does not exist because the Postgresql
JDBC driver does not support it.
If you raise this on pgsql-jdbc (so far, I haven't seen anything on that
list from you at all..)
Greg Stark wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Bernard was also objecting to the overhead of pushing the data down a
TCP pipe when it's already available locally, I think.. I didn't find
any real difference there when I compared the two methods, though.
What
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
>
>>It sounds like what you really want is the ability to grant something
>>like FILE access without granting all superuser rights? Sounds like a
>>feature request, not a bug, to me :-)
>
>
> AFA
Tom Lane wrote:
> What is the story on JDBC COPY support, anyway? I'm aware that there's
> an unofficial patch for that, but I'm not clear about why it's not made
> it into the accepted version.
I didn't like the whole "here is an undifferentiated stream of data"
approach -- there were some JDBC
Bernard wrote:
> 2) Split up security risk calculations between the two directions "TO"
> and "FROM" and relax security. Look at MySQL for clues. The
> application developer can manage security on file system permission
> level.
I looked at MySQL's docs briefly and its behaviour seems almost the
Bernard wrote:
> Oliver and interested list members:
[...]
And please fix your anti-spam system so it doesn't send me a "you must
jump through these hoops to send me email" message every time please!
(usual cc: to poster removed for that reason)
-O
---(end of broadcast)
Bernard wrote:
> This difference of performance is the main reason for the COPY
> command, and this is also the reason why bulk loading through the JDBC
> interface will never match the performance of the COPY fith files
> command.
In some admittedly unscientific tests I see less than 10% differe
Bernard wrote:
> The majority of JDBC users trying to bulk load tables would not want
> to send the data through their connection. This connection is designed
> to send commands and to transfer only as much data as necessary and as
> little as possible.
I don't understand why this is true at all
Bernard wrote:
> I want to follow what is suggested here. How are STDIN and STDOUT
> addressed when using the JDBC driver?
The current JDBC driver doesn't support this mode of COPY.
There was some work done in the past to support this but it never got to
the point of making it into the official
Alvaro Herrera wrote:
> Looks very much like the table was corrupted. Maybe you should try to
> test your RAM and disks. Not sure how to do that on x86-64 though,
> unless the test utility at www.memtest86.com has been ported to it.
x86-64 systems will still boot and run 32-bit code fine (altho
Alvaro Herrera wrote:
> On Sun, Jul 10, 2005 at 01:05:10PM +0300, Denis Vlasenko wrote:
>
>>On Thursday 07 July 2005 20:43, Alvaro Herrera wrote:
>
>
>>>Really? I thought what really happened is you had to get the results
>>>one at a time using the pg_fetch family of functions. If that is true
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
>
>>Sure, expression optimization is less aggressive, but is that on its own
>>really going to produce a 100-fold difference in query execution?
>
>
> It's certainly possible, depending on quer
Andrew - Supernews wrote:
> The problem is that even with the unnamed statement and deferred planning,
> the planner still has to treat the parameters as variables, not constants,
> since nothing in the protocol stops you from running multiple portals from
> the unnamed statement. This can make a
Ernst Bachmann wrote:
> The following bug has been logged online:
>
> Bug reference: 1753
> Logged by: Ernst Bachmann
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.3
> Operating system: Linux
> Description:Query Optimizer does not work well with libpg /
Gilles Dubochet wrote:
>>> Whith the JDBC driver at least up to version 8.1dev-400, the result
>>> of the
>>> getPrecision method of ResultSetMetaData on a bigint column is 0
>>> instead of
>>> the expected 19.
>>>
>>
>> This has been reported before but I haven't got to fixing it yet. This
>> is
Gilles Dubochet wrote:
> The following bug has been logged online:
>
> Bug reference: 1712
> Logged by: Gilles Dubochet
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.2
> Operating system: Linux
> Description:JDBC column precision for bigint is 0
> Detail
Kjh wrote:
> The following bug has been logged online:
>
> Bug reference: 1646
> Logged by: Kjh
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0
> Operating system: windows XP
> Description:ERROR: column "mycolumn" is of type boolean but
> expression is of
Nathan Neuenschwander wrote:
> I am using a CachedRowSet, the JDBC driver for PG 8.0, and j2ee.
> If the target table contains a column of data type text, the following
> causes an SQLException with a message stating that a negative value was
> returned for the column display size. If the text co
Ingolf Knopf wrote:
> The following bug has been logged online:
>
> Bug reference: 1611
> Logged by: Ingolf Knopf
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.1
> Operating system: JDBC
> Description:reading a date-field by "ResultSet.getTimestamp()"
>
Ingolf Knopf wrote:
> "java.sql.PreparedStatement.executeUpdate()" throws "java.sql.SQLException",
> if the prepared sql-string contains '?' within a C-like comment.
>
> Example:
> select relname
> from pg_class
> where /*relowner = ? and*/
> relname = ?
>
> In this case, the java.sql.
Sergio Lob wrote:
Precision is the number of total digits in the number. Scale is the
number of fractional digits.
For instance, a column defined as NUMERIC(10,3) should return
precision=10, scale=3.
Yes, I understand that.
The error only occurs for a column defined as
NUMERIC (without precis
Sergio Lob wrote:
Bug to report - For a numeric in a table defined by:
CREATE TABLE SERG (F01NUM NUMERIC) ;
, the precision and scale reported by ResultSetMetaData.getScale() and
ResultSetMetaData.getPrecision() are value -1
What should they return instead in this case?
-O
-
(cc'ing -jdbc)
Sergio Lob wrote:
After calling Connection.DatabaseMetaData.getTypeInfo() method, the
PRECISION column of the ResultSet seems hardcoded to value 9, which of
course in incorrect
Well, it's working as intended in the sense that there is no code to
support retrieving a real precision v
Andreas Pflug wrote:
Oliver Jowett wrote:
postgresbugs wrote:
The functionality provided by PGPASSWORD should not be removed unless
there is a functionality other than .pgpass, which is fine for some
uses and not for others, that will provide similar functionality.
That could be psql and
postgresbugs wrote:
The functionality provided by PGPASSWORD should not be removed
unless there is a functionality other than .pgpass, which is fine for
some uses and not for others, that will provide similar functionality.
That could be psql and pg_dump and the like accepting a password on the
postgresbugs wrote:
Tom Lane wrote:
The point here is that if
PGPASSWORD is passed down to psql as an environmental variable, it is
visible as part of psql's environment for the entire run of psql.
Whatever the calling script does later doesn't remove that window of
vulnerability.
[...]
And, yes I
Tom Lane wrote:
- the user might not want to store their password in .pgpass
Without a concrete argument why they should not, this is a straw man.
I think this is the core of our disagreement.
Storing passwords on the client's disk is surely less secure than not
storing them on disk. That's my per
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
If you're a shell script calling psql / pg_dump / etc, how do you do this?
That doesn't strike me as a compelling case for inventing "--password-fd".
Such a shell script is going to have a hard time passing a pas
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Assuming that you can't tweak .pgpass (for example, you're just
propagating a password you interactively got from the user), what's the
recommended way to provide the password?
In the connection string given to PQcon
Tom Lane wrote:
postgresbugs <[EMAIL PROTECTED]> writes:
I would like to recommend removing the deprecation flag from PGPASSWORD.
Do you understand why it's deprecated? It's because on some operating
systems, everyone on the machine can see your environment variable
values (if they know how to l
Kobus Walters wrote:
Create a prepared statement with sql "select localtimestamp - time ?". Call setObject(1, java.lang.String) with the String value "00:00:00" for instance. In version 7 this gets executed as "select localtimestamp - time '00:00:00'", while version 8 try to execute it as "select l
Peter Eisentraut wrote:
Am Freitag, 4. Februar 2005 11:54 schrieb Rainer Frey:
Is there any possibility to set a timeout for the lock, after which the
ALTER TABLE statement fails, instead of remaining in wait status (when
calling with JDBC?
Yes, there is a statement_timeout parameter or something l
Simon Nicholls wrote:
Bug reference: 1410
PostgreSQL version: PostgreSQL 8.0
Operating system: WindowsXP
Description:Hibernate PerformanceTest is incredibly slow (in effect
unusable)
00:41:41,453 DEBUG SchemaExport:136 - drop table Simple
00:41:41,500 DEBUG SchemaExport:154 - create
raxfar wrote:
The following bug has been logged online:
Bug reference: 1402
Logged by: raxfar
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.0-rc2
Operating system: windows 2000
Description:getPrecision don't work
Details:
have
java.sql.ResultSetMetaData _oM
Tom Lane wrote:
Basically my point here is that the default "prefer" SSL mode
effectively becomes "require" if the server has a root.crt.
Ok, in the scenario where validation is important, clients should be
using "require" anyway, so it's not an issue so long as libpq doesn't
try to fall back to
Tom Lane wrote:
BTW, as of CVS tip, if the server has a root.crt file and the client
does not have any certificate files, the default behavior is that
connections fail:
$ psql -h localhost regression
psql: could not open certificate file "/home/tgl/.postgresql/postgresql.crt":
No such file or dire
Tom Lane wrote:
Kris Jurka <[EMAIL PROTECTED]> writes:
// To avoid this, we guess at how many queries we can send before the
// server -> driver stream's buffer is full (MAX_BUFFERED_QUERIES).
It seems essentially impossible for the driver to do this reliably,
since it has no clue how much
Kris Jurka wrote:
On Mon, 13 Dec 2004, PostgreSQL Bugs List wrote:
The following bug has been logged online:
Bug reference: 1347
PostgreSQL version: 8.0 Beta
Operating system: Windows XP
Description:Bulk Import stopps after a while ( 8.0.0. RC1)
- I have written a java program to t
Kris Jurka wrote:
I sent him a driver that was recompiled with MAX_BUFFERED_QUERIES = 1 and
he still appears to be having some problems, but I have no idea where.
I wonder if he is doing one transaction per batch update loop or
something similar. If there's a bottleneck on the server side that's
Tom Lane wrote:
"Robert Green" <[EMAIL PROTECTED]> writes:
I have noticed that using postgresql 7.4.2 at serializable level it is
possible for two users to update the database at the same time.
I ran your test program here and tracked down what the problem is.
What's happening is that the JDBC d
47 matches
Mail list logo
