Because many developers of postgres work over dialup modems at speeds of
32k. 500KB over a 32Kb line is a problem. Especially if you aren't
even planning on using jdbc, you still pay the price when doing a CVS
checkout.
--Barry
Rene Pijlman wrote:
> On Mon, 22 Oct 2001 19:22:19 -0400, Tom
Robert,
What version of the driver and database are you using? I have code that
gets the update count back from executeUpdate(). So I suspect this may
be fixed in a more recent version.
thanks,
--Barry
Robert Dyas wrote:
> Hi all,
>
> I have been using the JDBC driver for a couple of mont
t required by the spec.
thanks,
--Barry
Ned Wolpert wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Ok, I understand.
>
> So, why are people talking about support for JDBC3 where JDBC2 support isn't
> even there?
>
> On 26-Oct-2001 Barry Lind
The jdbc driver does not support updateable result sets. If you want to
update the data you need to do it the old fashioned way (i.e. use update
SQL statements).
thanks,
--Barry
Robinson wrote:
> Hello,
>
> I have a situation where I just want the changes to be made temporarily
> in the R
I'm not sure what doesn't work with the driver. (Course, I've been using
> PoolMan as the datasource to wrap the postgresql default connection rather than
> using the datasource object, so I haven't been testing this myself, yet.)
>
>
>
> On 26-Oct-2001 B
Jason,
Can you explain what this patch is attempting to fix? Given that we are
in beta with 7.2, I want to fully understand the problem here before
applying this patch. (Especially given that the diff is pretty large and
not a one or two line change).
Also what testing have you done on this?
Ned,
There really isn't a j2ee driver for postgres. If you build the j2ee
driver it is essentially the same as the j2se driver. So I don't see
any reason to confuse people by letting them think there really is a
difference by having two different java2 drivers to choose from on the
web site
Subject pretty much says it all. I have posted the 7.2beta1 jar files
up on the web site (jdbc.postgresql.org) for people to test if you don't
want to built it yourselves.
thanks,
--Barry
---(end of broadcast)---
TIP 5: Have you checked our ext
Paul,
The best way to get this patched in is to send a patch (diff -c format)
of the changes diffed against current sources to this list. Someone
from here will look at it and apply it to CVS.
A comment for you on your fixes. Have you looked at current CVS sources
to see if your problems st
The patch is missing the corresponding fix for
jdbc1/DatabaseMetaData.java. Can you resubmit the patch with a fix for
both occurances of the problem? Otherwise the fix looks fine.
thanks,
--Barry
Bruce Momjian wrote:
> Here is a patch for DatabaseMetaData to show precision properly. It is
Per-Olof,
Thanks for the constructive feedback.
Let me try to answer your questions:
> 1. How is the driver compliance tests carried out? The test harness from
> sun?
The sun test harness has been run. However the sun test harness is only
for jdbc2 + the enterprise extensions. As far as I
Mark,
Any help on moving the jdbc code base forward is more than welcome. In
briefly looking over your suggestions below they all seem fine to me.
(Of course the devil is in the details). I would also suggest looking
at http://lab.applinet.nl/postgresql-jdbc for a list of where we are
lacki
l solution is (and there probably
isn't an ideal solution), thus I feel we should stick with status quo
for 7.2 and deal with all of this in a few months after 7.2 is production.
thanks,
--Barry
Tom Lane wrote:
> Barry Lind <[EMAIL PROTECTED]> writes:
>
>>If we can inc
19 Oct 2001 10:45:43 -0700 (MST)
> Sender: [EMAIL PROTECTED]
> From: Ned Wolpert <[EMAIL PROTECTED]>
> To: Barry Lind <[EMAIL PROTECTED]>
> Subject: Re: [JDBC] [PATCHES] Ant configuration
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Two cents
Per-Olof Norén wrote:
> Hi all,
>
> I have been listening to the discussions about Ant and the build system.
>
> I think that the discussion is missing a point, which I will try to make
> here :-)
>
>
>
> 1. Standard
>
> The Ant build system is making its way to be a "de facto" standard
Andrew,
I think I see the problem. (It was the 'invalid large obj descriptor
(0)' message that clued me in). The LargeObject reference is only valid
within a transaction. Thus if you have autocommit turned on, you
basically can't use LargeObjects. Because as soon as the sql is
executed to
I would suggest starting with the 7.1 drivers off of
jdbc.postgresql.org. The functionality they provide for
Blobs/LargeObjects matches the documentation you are using.
You can also try the 7.2 drivers that you can also download from
jdbc.postgresql.org. In these drivers the implementation o
Marko,
>
> But it seems to me that Ant has a positive side too:
I agree that there are positive reasons to use Ant (that is why it was
done in the first place). It is just that in retrospect, I don't
believe the pluses outweigh the minuses.
>
> * People with Java background probably know
The error stack you had in your original email indicates you are running
a 7.2development version of the driver. Since QueryExecutor didn't
exist in 7.1. (Sorry I didn't explain how I came up with the conclusion
you were running 7.2development code).
>>at org.postgresql.core.QueryExecutor.e
The problem here could be a number of different things. Let me walk
through the ones I can think of.
1) You really should be using a PreparedStatement for this query you are
doing, so that the driver can escape any special characters you may have
in your bind value. Right now if your t1 value c
I don't
> know.
>
> Barry Lind wrote:
>
>> Anyone can do that by submitting a patch. I don't see anything
>> special that needs to be done.
>>
>> --Barry
>>
>> Joseph Shraibman wrote:
>>
>>> Right. And a maintainer needs to
the right direction
people want the jdbc driver to go.
thanks,
--Barry
Marko Kreen wrote:
> On Wed, Oct 17, 2001 at 01:23:13PM -0700, Barry Lind wrote:
>
>>I don't like this patch. If anything I think we should remove the
>>dependency on ANT, not remove the dependency o
The problem is that you are using current development code with
instructions that are written for 7.1.
You can either get the 7.1 jdbc drivers which should work according to
the documentation you are using, or you can use the 'compatible'
parameter to set the behavior in the 7.2 driver back to
I don't like this patch. If anything I think we should remove the
dependency on ANT, not remove the dependency on make.
By requiring ANT, we provide yet another hurdle for someone wanting to
use JDBC with postgres. I would prefer that the build environment be
the same for the database as for
This really doesn't have anything to do with 1.4. If you think you have
a bug, please send an email to the list with instructions on how to
reproduce (and a test case showing the problem that could be compiled
and run would be really great as well). Or even better get the source
code and deb
Anyone can do that by submitting a patch. I don't see anything special
that needs to be done.
--Barry
Joseph Shraibman wrote:
> Right. And a maintainer needs to make a jdbc3 direcotry and modifiy the
> ant files to use it when it detects a jdk of 1.4+
>
>
> Dave Cramer wrote:
>
>> What d
Attached is a proposed fix for a bug in DatabaseMetaData.getIndexInfo().
This fixes a bug reported by [EMAIL PROTECTED] On Sept 7th,
he sent a test case to the list demonstrating the bug. His test case
now works successfully with this patch. If no one has any objections to
this patch, I w
functions in PostgreSQL are called via a select statement.
Issue "select your_custom_function()" in a Statement or
PreparedStatement. Then get the result like any other select statement
via the ResultSet.
thanks,
--Barry
Oleg Lebedev wrote:
> Hi,
> I created a PL/pgSQL function, but can not
It should be returning an Integer object. In a brief look at the source
code it seems to be doing the correct thing. What version are you using?
Also I noticed your example below:
System.out.println("The result is: " + (String) obj);
This shouldn't work. You can't cast any random object
Forwarding this message to the jdbc list.
Mihai Gheorghiu wrote:
> Is it possible to have the backend messages displayed by the front end?
> More precisely: I'm accessing PG via JDBC. Can JDBC driver convey PG server
> error messages to the front, or I can get only what JDBC throws?
> Thank yo
Mihai,
Do you have specific examples of the error messages you want on the
front end? As far as I know all error messages that result from a
particular client are sent back to that client. Either as errors (ERROR
messages), or as warnings (NOTICE messages). Error messages get thrown
via a
David,
This is a problem in the driver. I believe it is fixed in current
sources. Can you download the latest development build from
jdbc.postgresql.org and see if that works for you?
thanks,
--Barry
David Brownlee wrote:
> (I'm not subscribed to the list, please cc directly in repli
Chris,
Current sources for the jdbc driver does support the bytea type.
However the driver for 7.1 does not.
thanks,
--Barry
Chris Bitmead wrote:
> >Use bytea, its for 0-255, binary data. When your client
> >library does not support it, then base64 it in client side
> >and later decode()
Ben,
Cursors are supported. My guess as to your problem (since you didn't
send a full code example of what you are doing) is that you need to
issue multiple 'fetch' statements. Each fetch statement will return its
own result set. So when you have used up the results from one fetch
statemen
Mail like this doesn't help the situation any. Would you mind telling
us what version you are having problems with? Suppling a test case that
reproduces the problem would be better, and providing a patch that fixes
the problem would be best of all.
This is an open source project. Things get
Dave,
I share your concerns about this functionality. In fact last month I
wrote the following in response to a patch to this functionality.
I wouldn't mind this being pulled out of the main code line for now and
moved to contrib until it becomes more robust.
>>Robert,
>>
>>
>>Thanks
Dave,
I share your concerns about this functionality. In fact last month I
wrote the following in response to a patch to this functionality.
I wouldn't mind this being pulled out of the main code line for now and
moved to contrib until it becomes more robust.
>>Robert,
>>
>>
>>Thanks for
Dave,
I can't explain what is happening here. I think the best next step is
to turn on query logging on the server and look at the actual SQL
statements being executed. It really looks like some extra commits or
rollbacks are occuring that is causing the locks to be released.
thanks,
--Barr
f the behavior of
using select for update:
The select for update will block other 'select for updates' or
'updates'. It does not block other simple selects. But that is fine
for the purposes here.
thanks,
--Barry
Dave Harkness wrote:
> At 01:45 PM 10/2/2001,
This jar is a jdbc2.0 jar. However, It isn't fully complient with the
jdbc2.0 spec. You will see much better complience if you upgrade to
7.1. But even in the forthcomming 7.2, there are some areas where the
driver still isn't fully complient. But it is getting better all of the
time. Is
They should be. Is the \o a typo below, or are you really trying to
send \o?
thanks,
--Barry
Heitzso wrote:
> PreparedStatement setString(i, s)
>
> i.e.
>
> p = connection.preparedStatement("SELECT a FROM b WHERE c = ?");
> String s = "hello\t\out\r\nthere\t\t\t\r\n";
> p.setString(1, s);
>
Heirzso,
There is no limit. What version of the database and jdbc driver are you
using? Also, can you turn on database debug so that the server prints
out the exact sql statement it is getting from the jdbc client? (this
statement will have the bound values from the prepared statement in it
OK, this is a known bug. It should be fixed in current sources. Try
using the 7.2 driver from the jdbc.postgresql.org website and see if
that works correctly for you. If you search the email archives you can
find a discussion on this bug.
thanks,
--Barry
David Siebert wrote:
> It looks as
Dave,
First off, are you running with autocommit turned off in JDBC? By
default autocommit is on, and thus your lock is removed as soon as it is
aquired.
Secondly, you don't need a table lock, you just need to lock the row
between the select and the update. You should use 'select for update
Dave,
My thoughts as well. If we encounter an 'unknown' type, just return it
as a String. Do you have time to fix this?
As a work around using an explicit cast should also work:
select container_20_ft_qty AS QTY_OH, 'Container'::text AS NOMENCLATURE
from ue_summary_mtmc where uic = 'WAQJAA'
You need to run configure first (with the --with-java option) first,
before building the driver.
--Barry
Grant Edwards wrote:
> Hi,
>
> Need a bit of help please, some config stuff first followed by the error.
> Any info will be greatly appreciated emails can be sent to
> [EMAIL PROTECTED] o
It works fine for me. I can download and unzip the file. Are you still
seeing this problem?
thanks,
--Barry
Ray Tomlinson wrote:
> http://jdbc.postgresql.org/download/jdbc7.1-1.2.jar has bad format.
> Neither winzip nor jar can read the contents. Jar throws an
> IllegalArgumentException and
David,
Can you specify the exact error you are getting? along with the database
version, jdbc version and java version you are running? Also a test
case that demonstrates the problem would be very helpful as well.
thanks,
--Barry
David Siebert wrote:
> I am having problems with getTimestamp
The subject pretty much says it all. I have updated the jdbc website to
contain more current information. It certainly could contain more
information, but my primary goal was to get it current. If you have any
suggestions, changes or additions please send them to the mail list.
thanks,
--B
Since you are doing a select * without any where clause, postgres is
going to return the entire table back to the client all at once. The
client then needs to store the entire result in memory, thus you will
need enough memory to hold the entire table in memory.
A better way to do this in postgr
Vic,
Can you post the errors you are getting for both the build problem and
the runtime problem you originally reported?
Without the exact errors you are getting, I can only guess at the
problems you are encountering. But my guess as to your original problem
is that your code is trying to us
The jdbc driver is OS independent. It doesn't matter which platform the
driver is compiled on, it will run on any platform that supports a java
runtime.
As far as jdk1.2 vs jdk1.3 goes, a driver compiled by a 1.2 jdk will
work fine under jdk1.3. The code is identical for these two jdk
relea
No it does not.
thanks,
--Barry
jcooney wrote:
> Does the 7.1-1.3 driver availalble on fastcrypt support JDBC 2.0 driver based
> connection pooling?
>
> I'm more than willing to look up the answer to this myself if someone can
> point be towards some technical documentation.
>
> Thanks,
>
Matt,
Have you verified that this large object (id=12992) exists in your
database? (select distinct loid from pg_largeobject where loid = 12992)
If it doesn't, I think then the place to look is the code that you used
to insert the large objects as it would appear that code didn't do the
inser
Yes this is a known bug. It is fixed in the 7.1 JDBC driver. The 7.1
driver should work fine against a 7.0 database.
thanks,
--Barry
Whitney Hunter wrote:
> Hi,
>
> I am trying to read a Timestamp value from a ResultSet and am getting the
> following exception:
>
> Bad Timestamp Format at
Ola,
I don't think this logic should be coded into the JDBC driver. Instead
I think it makes much more sence to have this logic coded into the
backend and then exposed via JDBC and the other interfaces. I know that
someone is working on doing the same thing in ODBC. Having the same
code do
Patch looks good.
thanks,
--Barry
Rene Pijlman wrote:
> Attached is a patch that fixes ResultSetMetaData.isNullable() in
> the JDBC driver.
>
> This method is currently unimplemented and always returns
> ResultSetMetaData.columnNullable. This is obviously incorrect
> when a column is defined wi
Dave,
The protocol for the clients to talk with the backend server doesn't
support the concept of a fetch size. When a query is executed it's
entire result is sent to the client. (You can explicitly work around
this by using cursors see the DECLARE and FETCH sql commands).
thanks,
--Barry
Peter,
Good question. There was a mail thread on this probably about six
months ago. IIRC this was done so that you could call getBoolean() on
an integer column. I think that some other database supported this and
they wanted to have postgres support it in the same way. I think that
is wh
Bruce,
This patch is fine.
thanks,
--Barry
Bruce Momjian wrote:
> I noticed that jdbc1 getBoolean allows '1', while jdbc2 does not. The
> following patch makes jdbc2 accept '1' also. Is this OK?
>
>
>
>
>
> Index: s
Alexaki,
I am unsure what you mean by very long transaction. A transaction is
defined by issueing a 'begin' statement, followed sometime later by a
'commit' or 'rollback'. Therefore a long transcation would imply a long
period of time between the begin and the commit or rollback. There is
Culley,
What do you get when you issue the following select statements:
select getdatabaseencoding();
select datname, encoding from pg_database;
thanks,
--Barry
Culley Harrelson wrote:
> Ack! I guess I am hitting this problem
>
> I had my database rebuilt to use UNICODE encoding. Dat
>>>
>>>>
>>>>
>>>>>I've added a new section "Character encoding" to
>>>>>http://lab.applinet.nl/postgresql-jdbc/, based on the
>>>>>information from Dave and Barry.
>>>>>
>>>>>I
gt;>>I've added a new section "Character encoding" to
>>>>http://lab.applinet.nl/postgresql-jdbc/, based on the
>>>>information from Dave and Barry.
>>>>
>>>>I haven't seen a confirmation from pgsql-hackers or Bruce y
Larry,
Shouldn't your connection URL be:
jdbc:postgresql://localhost:5432/testdb
instead of
jdbc:postgresql://localhost:5432?database=testdb
thanks,
--Barry
Larry Rogers wrote:
> Hi all,
>
> I'm having trouble opening a database connection to a test database on a
> fresh PostGreSQL 7.1.3
Rene,
Since the FE/BE protocol deals only with string representations of
values, the protocol doesn't have too much to do with it directly. It
is what happens on the client and server sides that is important here.
Under the covers the server stores all timestamp values as GMT. When a
select
list. I'm under the
>>impression that the backend developers don't see this as a
>>problem.
>>
>>Regards,
>>Ren? Pijlman
>>
>>On Tue, 04 Sep 2001 10:40:36 -0700, Barry Lind wrote:
>>
>>>I would like to add one additional comment.
and Barry.
>
> I haven't seen a confirmation from pgsql-hackers or Bruce yet
> that this issue will be added to the Todo list. I'm under the
> impression that the backend developers don't see this as a
> problem.
>
> Regards,
> René Pijlman
>
> On Tu
The patch looks OK to me. (And yes a recent patch I did started using
set session characteristics, prior to that the code was explictly
setting the isolation level after every begin.)
thanks,
--Barry
Rene Pijlman wrote:
> Attached is a patch that fixes
> ConnectionTest.testTransactionIsolatio
If you have the time this weekend to work on addressing this, that would
be great.
thanks,
--Barry
Rene Pijlman wrote:
> On Thu, 06 Sep 2001 23:39:53 -0700, you wrote:
>
>>Interestingly it was fixed in the getColumns() method, until a patch
>>that was applied yesterday broke it again.
>>
>
>
Your recommendation to leave the behavior as is and change the
regression test is fine with me.
thanks,
--Barry
Rene Pijlman wrote:
> The ConnectionTest test case in our own jdbc2 test suite fails
> to set and get the transaction isolation level correctly. After
> looking at the implementation
I believe this was done a while ago. (It looks like it was patched on
Aug 17 by a patch from Rene).
thanks,
--Barry
Bruce Momjian wrote:
> Can someone tackles this and supply a patch?
>
>
>
>>Would some JDBC hacker develop a patch for the following issue? The
>>change is just barely large
Looks good.
--Barry
Dave Cramer wrote:
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Cramer
> Sent: September 4, 2001 1:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JDBC] Read transactions don't work on 7.0.x db's 2nd patch
>
>
> Here
e the solution that will emerge in the long term
>>| anyway; but do we have candidate patch-meisters now?
>>|
>>| Comments, better ideas, nominations, volunteers?
>>
>
>>I would like to nominate Barry Lind as he has been doing great work for a
>>l
x27;t think it
is worth the hassle, and I can live with the existing format.
thanks,
--Barry
Dave Cramer wrote:
> Well, my vote would be for a 2 space indent.
>
> Dave
> On Tue, 2001-09-04 at 16:59, Tom Lane wrote:
>
>>Barry Lind <[EMAIL PROTECTED]> writes:
>>
&g
Dave,
There is a bug in this patch. In the rollback case, you have:
> ! ExecSQL("rollback; begin"+getIsolationLevelSQL());
You are missing a semicolon after the begin.
thanks,
--Barry
Dave Cramer wrote:
> Here is a revised patch with Barry's suggestions implemented
>
> Dave
>
>
>
removed from the database in 7.0 and from the
JDBC driver in 7.0.2. Therefore I don't think we should code for the
case of a 7.2 JDBC driver needing to support a 6.5 database.
thanks,
--Barry
Rene Pijlman wrote:
> On Mon, 27 Aug 2001 22:57:13 -0700, Barry Lind wrote:
>
>>I
Joseph,
In looking at this patch it looks OK, except for the following change:
> ! if (index>=-rows.size())
> --- 725,737
> ! if (index > rows_size)
I haven't looked at the entire method, but the change you made seems
incorrect.
If you want this patch to be applied it
I agree that this is needed. In fact I know Bruce wants to do something
in this area. In fact he sent out a few months ago a sample of the code
after it had been cleaned up by some tool. At the time no one seemed to
be very interested. Going forward for 7.2 I think now is the time that
som
One reason is that jdbc2 goes along with Java2. Thus in the jdbc2 tree
we are allowed to use new methods introduced in jdk1.2. Whereas in the
jdbc1 tree we are limited to methods available in jdk1.1.
thanks,
--Barry
Rene Pijlman wrote:
> Perhaps this is a silly question, but why do we have s
d);
>>props.put("charSet",encoding);
>>Connection con = DriverManager.getConnection(url,props);
>>where encoding is the proper encoding for your database
>>
>
> For completeness, I quote the answer Barry Lind gave yesterday.
>
> "[the driv
ux machine from sun.com as my java platform
> and
> And perl, v5.6.0 built for i386-linux.
> The PostgreSQL driver for perl came from www.perl.org
> The postgreSQL driver in jdbc7.0-1.2.jar
>
>
> Barry Lind wrote:
>
>
>>Andy,
>>
>>I would be in
ithin
the last year. For example since 7.1 came out in April 2001, this would
mean supporting 7.0 until April 2002. And if 7.2 when production in
October 2001, then 7.1 should be supported until October 2002.
thanks,
--Barry
Tom Lane wrote:
> Barry Lind <[EMAIL PROTECTED]> writes:
>
Andy,
I would be interesting in knowing what version you did this test on,
what platform, and most importantly which JDK (and if the Sun JDK which
JVM: classic, hotspot client, hotspot server).
thanks,
--Barry
andy wrote:
> Hi,
>
> I ran a few bench marks on JAVA writing to a postgreSQL tabl
Kovács Péter wrote:
>>the driver what character set the backend is sending us? Can't
>>it ask the backend dynamically?
>>
>>
>
> This is what it actually does, isn't it? (Based on what I usually see in the
> trace output on the backend.) I tested a unicode database with varchar(255)
> fields an
Dave,
The multiple statements in one call is there for performance reasons.
Please don't remove it entirely since it works fine in 7.1 and 7.2.
Instead your fix should be conditional based on server version:
if (autoCommit)
ExecSQL("end");
else {
ifMinumumServerVersion("7.1") {
Exec
Is there a reason you are not using getBinaryStream()? You can't read a
binary file with and AsciiStream.
thanks,
--Barry
Isabelle Therrien wrote:
> Hi
>
> I've seen a couple of discussion about this subject, and I wonder if you
> could help me finding a workaround for my problem too.
>
> I
The java part of this patch looks OK to me. I don't know the internal
postgres table structures well enough to have any meaningfull comments
on the SQL statement.
As for this only supporting 7.1 and higher, that is OK IMHO. We have
only really tried beginning with the 7.2 release to maintain
Dave,
You never really explained what the problem was. What error were you
getting, and what does this fix solve?
Also, the patch you have sent reports the entire file as being changed.
That is not useful to review. Can you send a followup to the list
with a better explaination and a pa
Ricardo,
Is your database compiled for multibyte support? And what character set
is the database you are connecting to created with? (to get the
database character set do a 'psql -l'). If the answer to the first
question is no or the answer to the second question is 'SQL_ASCII', then
only
Yes I have seen this behavior as well (first run has many failures, but
later ones succeed). One reason that I noticed had to do with test
setup code. Many of the tests do the following:
drop table foobar;
create table foobar (...);
The first time this is run on a clean database the drop ta
tea xfunc-c.html:>bytea xfunc-c.html:>(bytea *)
> but no real info on what it is, or no mention of it in the main types page.
> Anyway, I think I'm fine for now, stipping the null chars from my data.
>
> Tom.
>
> On Tue, Aug 28, 2001 at 09:17:19PM -0700, Barry Lind wro
ok into why and report back if
>>I find anything.
>>
>>Cheers,
>>
>>Tom.
>>
>>On Tue, Aug 28, 2001 at 12:56:50PM -0700, Barry Lind wrote:
>>
>>>Thomas,
>>>
>>>If you turn on debug messages on the server to print out th
"
>
> should be left alone. ie, if we're in a string escape processing should
> not be done. Right now it looks for anything with {d in the query and
> starts changing it.
>
> Cheers,
>
> Tom.
>
> On Tue, Aug 28, 2001 at 12:55:19PM -0700, Barry Lind wrote:
Bruce,
I think the existing patch can be applied as is. The issues I raised
below are further improvements in the functionality that can be done and
don't directly relate to the patch that was submitted. Sorry if I
confused things.
--Barry
Bruce Momjian wrote:
> Can someone suggest what is
Thomas,
If you turn on debug messages on the server to print out the SQL
statements it receives you should be able to get the exact string that
the server is receiving from the client and failing on. That might help
you find the problem.
thanks,
--Barry
Thomas O'Dowd wrote:
> Hi all,
>
> I
Thomas,
This is doing exactly what it is supposed to according to the JDBC Spec.
In fact there are a bunch of other '{X }' things that the Spec
defines that it should also be handling.
thanks,
--Barry
Thomas O'Dowd wrote:
> Hi all,
>
> The Connection.EscapeSQL() routine is broken IMHO .
Rene,
The patch looks good. Thanks for your time and effort.
thanks,
--Barry
Rene Pijlman wrote:
> Attached is a patch for current CVS, consisting of a cvs diff -c
> for the changed files and a few new files:
> - test/jdbc2/BatchExecuteTest.java
> - util/MessageTranslator.java
> - jdbc2/PBatch
> What exactly is the behaviour of the backend in that scenario?
> Does it commit every separate SQL statement in the
> semicolon-separated list, or does it commit the list as a whole?
> Does it abort processing the statement list when an error occurs
> in one statement? And if it continues,
I looked at the patch and it looks fine. As for what fqp and hfr stand
for I don't have a clue. I was looking through the fe/be protocol
documentation and think I might have a clue about what they are being
used for.
thanks,
--Barry
Anders Bengtsson wrote:
> Hi,
>
> Attached is my attempt
1 - 100 of 145 matches
Mail list logo
