From: thomas at tada.se (Thomas Hallgren)
Date: Mon, 15 May 2006 11:34:58 +0200
Subject: [Pljava-dev] PL/Java 1.3.beta released.
In-Reply-To: <003901c677f8$d88000a0$1e03a8c0@fhrbek>
References: <44673B92.9030109@tada.se> <003901c677f8$d88000a0$1e03a8c0@fhrbek>
Message-ID: <44684B42.2000809@tada.se>

Filip,
The makefile change that you describe is a no-op from what I can see. 
What is the real problem? I have no problems whatsoever compiling on 
Linux. Windows is fine too.

The change in the deployer seems worth doing. I opt for using the 
rollback. Either it works or it fails completely.

Regards,
Thomas Hallgren

Filip Hrbek wrote:
> Hi Thomas,
>  
> I have 2 comments to the new beta version of pljava.
>  
> The first one is about compilation problems on my platform (RedHat 
> Linux 9.0):
>  
> [root at devlin2 org.postgresql.pljava]# make
> make[1]: Entering directory 
> `/home/fhrbek/eclipse/workspace/org.postgresql.pljava/build/classes/pljava'
> /home/fhrbek/eclipse/workspace/org.postgresql.pljava/src/java/pljava/Makefile:37: 
> *** commands commence before first target.  Stop.
> make[1]: Leaving directory 
> `/home/fhrbek/eclipse/workspace/org.postgresql.pljava/build/classes/pljava'
> make: *** [pljava_all] Error 2
> The problem is in org.postgresql.pljava/src/java/pljava/Makefile at 
> following lines
>  
> JNI_CLASSES := \
>  org.postgresql.pljava.internal.Backend \
>  org.postgresql.pljava.internal.SPI \
>  org.postgresql.pljava.internal.AclId \
>  org.postgresql.pljava.internal.ErrorData \
>  org.postgresql.pljava.internal.Oid \
>  org.postgresql.pljava.internal.ExecutionPlan \
>  org.postgresql.pljava.internal.JavaWrapper \
>  org.postgresql.pljava.internal.LargeObject \
>  org.postgresql.pljava.internal.PgSavepoint \
>  org.postgresql.pljava.internal.Portal \
>  org.postgresql.pljava.internal.Relation \
>  org.postgresql.pljava.internal.Session \
>  org.postgresql.pljava.internal.SubXactListener \
>  org.postgresql.pljava.internal.TriggerData \
>  org.postgresql.pljava.internal.Tuple \
>  org.postgresql.pljava.internal.TupleDesc \
>  org.postgresql.pljava.internal.XactListener \
>  org.postgresql.pljava.jdbc.Invocation \
>  org.postgresql.pljava.jdbc.SingleRowReader \
>  org.postgresql.pljava.jdbc.SQLInputFromChunk \
>  org.postgresql.pljava.jdbc.SQLOutputToChunk \
>  org.postgresql.pljava.jdbc.SQLInputFromTuple \
>  org.postgresql.pljava.jdbc.SQLOutputToTuple
> I modified it in this way:
>  
> INTPKG  := org.postgresql.pljava.internal
> JDBCPKG  := org.postgresql.pljava.jdbc
>  
> JNI_CLASSES := \
>  $(INTPKG).Backend \
>  $(INTPKG).SPI \
>  $(INTPKG).AclId \
>  $(INTPKG).ErrorData \
>  $(INTPKG).Oid \
>  $(INTPKG).ExecutionPlan \
>  $(INTPKG).JavaWrapper \
>  $(INTPKG).LargeObject \
>  $(INTPKG).PgSavepoint \
>  $(INTPKG).Portal \
>  $(INTPKG).Relation \
>  $(INTPKG).Session \
>  $(INTPKG).SubXactListener \
>  $(INTPKG).TriggerData \
>  $(INTPKG).Tuple \
>  $(INTPKG).TupleDesc \
>  $(INTPKG).XactListener \
>  $(JDBCPKG).Invocation \
>  $(JDBCPKG).SingleRowReader \
>  $(JDBCPKG).SQLInputFromChunk \
>  $(JDBCPKG).SQLOutputToChunk \
>  $(JDBCPKG).SQLInputFromTuple \
>  $(JDBCPKG).SQLOutputToTuple
> and now it works.
> Should I commit this change, or is there any other solution?
>  
>  
> The second comment is about an improvement in the pljava deployer.
> If an error occurs during pljava installation (e.g. no pljava.so/dll), 
> a piece of unfinished pljava system may remain in the database. Then 
> it is impossible to retry unless you drop all those objects manually, 
> which might be inconvenient, especially for beginners. I put the 
> installation process into a transaction which seems to solve all this.
> The only problem was dropping the pljava and pljavau languages when 
> uninstalling pljava - this piece of code is in a try-catch block where 
> any exception is ignored. If it fails inside a transaction, any 
> following command fails due to "current transaction is aborted" error. 
> I solved this by using either a savepoint (if available), or a 
> transaction rollback (if savepoints are not available; this workaround 
> required the dropSQLSchema method to be the first one called in the 
> transaction).
>  
> If you like the above described modifications, I will commit them into 
> CVS so that you could see the changes.
>  
> Regards,
>     Filip
>  
>  
> ----- Original Message -----
> From: "Thomas Hallgren" <thomas at tada.se <mailto:thomas at tada.se>>
> To: "Pljava-Dev at Gborg.Postgresql.Org 
> <mailto:Pljava-Dev at Gborg.Postgresql.Org>" 
> <pljava-dev at gborg.postgresql.org <mailto:pljava-dev at gborg.postgresql.org>>
> Sent: Sunday, May 14, 2006 4:15 PM
> Subject: [Pljava-dev] PL/Java 1.3.beta released.
>
> > This release is about type mapping and the creation of new types in
> > PL/Java. An extensive effort has gone into making the PL/Java type
> > system extremely flexible. Not only can you map arbitrary SQL data 
> types
> > to java classes. You can also create new scalar types completely in 
> Java.
> >
> > The new type system also handles domains, arrays, and pseudo types like
> > "any", anyelement, and anyarray.
> >
> > The new release can be picked from the PL/Java download page at
> > http://wiki.tada.se/display/pljava/Download+Page.
> >
> > The final release is planned for end of May. If you have any known
> > issues or problems with PL/Java, please report them now. All testing
> > that is done on this beta release will help improve the quality of
> > PL/Java so please start pounding on it.
> >
> > Kind Regards,
> > Thomas Hallgren
> >
> > _______________________________________________
> > Pljava-dev mailing list
> > Pljava-dev at gborg.postgresql.org <mailto:Pljava-dev at gborg.postgresql.org>
> > http://gborg.postgresql.org/mailman/listinfo/pljava-dev