Re: 7.3 top-of-tree compilation error on OSX

Drew,

Any luck getting it to compile?

Here's a couple of things:

1) The precompiled jar will work just fine, even on a mac
2) If you are re-compiling, ie this isn't the first time, try make clean
in the jdbc directory
3) Try getting the latest sources off of cvs

Dave
On Fri, 2002-10-11 at 13:02, Drew Wilson wrote:
> 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
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
>