7.3 top-of-tree compilation error on OSX

I'm getting a compilation error when trying to build the latest pgsql
sources.

Here's ant's error log:
examples:
     [javac] Compiling 8 source files to
/Volumes/data/Users/drew/sources/TAOWO/tools/pgsql/src/interfaces/jdbc/
build
     [javac]
/Volumes/data/Users/drew/sources/TAOWO/tools/pgsql/src/interfaces/jdbc/
org/postgresql/jdbc1/AbstractJdbc1Connection.java:269:
encode(java.lang.String,java.lang.String,java.lang.String) in
org.postgresql.util.MD5Digest cannot be applied to
(java.lang.String,java.lang.String,byte[])
     [javac]
byte[] digest = MD5Digest.encode(PG_USER, password, md5Salt);
     [javac]
                              ^
     [javac] Note: Some input files use or override a deprecated API.
     [javac] Note: Recompile with -deprecation for details.
     [javac] 1 error

Sorry, I couldn't figure out the problem from looking at the two files,
org/postgresql/jdbc1/AbstractJdbc1Connection.java and
org/postgresql/util/MD5Digest.java.

FYI - I'm building on Mac OS X 10.2, with the following configuration.
./configure
--prefix=/Volumes/data/Users/drew/sources/TAOWO/buildresults/postgres
--bindir=/Volumes/data/Users/drew/sources/TAOWO/buildresults/bin/
--enable-recode --with-java --without-readline --enable-syslog
--enable-unicode-conversion --enable-multibyte --enable-cassert
--enable-debug.

Thanks for any help,

Drew

On Friday, October 11, 2002, at 09:42  AM, Barry Lind wrote:

>
>
> Aaron Mulder wrote:
>>     You may be able to configure your app server database pools to
>> cache PreparedStatements.  Some version of JBoss and WebLogic support
>> this, at any rate.  The idea is that just like connections aren't
>> really
>> closed when you call close (just returned to the pool), PSs aren't
>> really
>> closed when you call close (just kept in a cache for the connection).
>>  This would let you take advantage of server side PSs in an app >> server
>> environment.
>>     The danger is that if each connection has a high PS cache size, you
>> can run into problems like "too many open cursors" on Oracle (when 50
>> connections each try to cache 50 PSs or whatever).
>
> Oracle's max open cursors is per connection.  So as long as it is set
> higher than the size of the statement cache you should be ok.  I also
> beleive that in recent versions of the oracle jdbc driver, the driver
> does this statement caching automatically.  It shouldn't be too
> difficult to add statement caching to the postgres jdbc driver if we
> thought it would be a good idea.
>
>> I'm not sure whether PostgreSQL would complain or not.  Does it
>> support multiple open PreparedStatements per Connection?  And if so,
>> are there any backend limits to the total number of open server side
>> PSs?
>
> Yes it does support mulitple server side prepared statements.  There
> isn't any limit on the backend (other than available memory) on the
> number.
>
>
>> Aaron
>
> --Barry
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>