Hi,

I'm trying to install PL/Java on Postgres 9.2.4 and it fails.

I downloaded : http://pgfoundry.org/frs/download.php/3280/pljava-src-snapshot.20120525.0.tar.gz

I could able to make and install.

I'm getting following 2 errors while running install.sql:

psql -U postgres -h localhost < pljava-snapshot.20120525.0/src/sql/install.sql
CREATE SCHEMA
GRANT
ERROR: incompatible library "/opt/local/lib/postgresql92/pljava.so": version mismatch
DETAIL: Server is version 9.2, library is version 9.1.
ERROR: function sqlj.java_call_handler() does not exist
ERROR: incompatible library "/opt/local/lib/postgresql92/pljava.so": version mismatch
DETAIL: Server is version 9.2, library is version 9.1.
ERROR: function sqlj.javau_call_handler() does not exist

ERROR: language "java" does not exist

am I missing something?

Hi,

I can't found docker image on docker hub so I created one myself.
PLJava from master branch and PostgreSQL 9.4.

https://hub.docker.com/r/xxbedy/postgres-pljava/

Bedy

I see that there is a problem with the 64bit build of pljava:
https://bugs.launchpad.net/ubuntu/+source/postgresql-pljava/+bug/1301150

Is anyone willing and able to look into this? It's way above my pay grade but I've come to rely upon pljava and no 64bit is a serious issue for me.

While trying to run the example provided along with installation, got below error.

DEBUG: Using integer_datetimes
DEBUG: Added JVM option string "-Djava.class.path=/opt/PostgreSQL/9.1/lib/postgresql/pljava.jar:/usr/share/java/postgresql-jdbc-8.1.407.jar"
DEBUG: Added JVM option string "-Dsqlj.defaultconnection=jdbc:default:connection"
DEBUG: Added JVM option string "vfprintf"
DEBUG: Creating JavaVM
DEBUG: JavaVM created
DEBUG: Getting Backend class pljava.jar
DEBUG: Backend class was there
java.lang.UnsatisfiedLinkError: _getStatementCacheSize
at org.postgresql.pljava.internal.Backend._getStatementCacheSize(Native Method)
at org.postgresql.pljava.internal.Backend.getStatementCacheSize(Backend.java:65)
at org.postgresql.pljava.internal.ExecutionPlan.(ExecutionPlan.java:108)
WARNING: java.lang.UnsatisfiedLinkError: _getStatementCacheSize
DEBUG: Destroying JavaVM...
DEBUG: JavaVM destroyed
ERROR: Unable to load class org/postgresql/pljava/internal/ExecutionPlan using CLASSPATH '-Djava.class.path=/opt/PostgreSQL/9.1/lib/postgresql/pljava.jar:/usr/share/java/postgresql-jdbc-8.1.407.jar'
STATEMENT: SELECT sqlj.install_jar('file://opt/PostgreSQL/9.1/pl/pljava-1.4.3/build/examples.jar', 'samples', true);

-bash-3.2$ java -version
java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_22-b03, mixed mode)
-bash-3.2$ uname -a
Linux 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

Hi

If this is not the right place to post these issues I beg you pardon.

Here is my question:

I haven't been able to compile on mac os el capitan and postgres 9.4

this is the postgres version I have

PostgreSQL 9.4.4 on x86_64-apple-darwin, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00), 64-bit

And this is what i get after running mvn install .

[ERROR]   "_textout", referenced from:
[ERROR]       _getAS in Function.o
[ERROR]   "_unknownrecv", referenced from:
[ERROR]       _UDT_receive in UDT.o
[ERROR]   "_unknownsend", referenced from:
[ERROR]       _UDT_send in UDT.o
[ERROR] ld: symbol(s) not found for architecture x86_64
[ERROR] clang: error: linker command failed with exit code 1 (use -v to see invocation)
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] PostgreSQL PL/Java ................................. SUCCESS [  1.479 s]
[INFO] PL/Java API ........................................ SUCCESS [  2.126 s]
[INFO] PL/Java backend Java code .......................... SUCCESS [  3.218 s]
[INFO] PL/Java backend native code ........................ FAILURE [ 11.206 s]
[INFO] PL/Java Deploy ..................................... SKIPPED
[INFO] PL/Java Ant tasks .................................. SKIPPED
[INFO] PL/Java examples ................................... SKIPPED
[INFO] PL/Java packaging .................................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 19.199 s
[INFO] Finished at: 2015-11-06T05:11:14+01:00
[INFO] Final Memory: 27M/368M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.1.0:nar-compile (default-nar-compile) on project pljava-so: NAR: Compile failed: g++ failed with return code 1 -> [Help 1]

Am I doing something wrong?

Regards.

Daniel

I am doing following to install PL/java with Postgresql 9.3.4 on Windows 7 64 bit System

1. I have downloaded PL/Java 64 bit binary package from pgFoundry (that is, pljava-x86_64-w64-mingw32-pg9.0-1.4.2.tar.gz) as there is no version of PL/Java for 9.3.4.
2. I have unpacked archive to C:\Program Files\PostgreSQL\9.3\share\pljava directory
3. I have put pljava.dll into C:\ProgramFiles\PostgreSQL\9.3\lib directory
4. I have added into postgresql.conf (data):
   custom_variable_classes = 'pljava'
   pljava.classpath='C:\Program Files\PostgreSQL\9.0\share\pljava\pljava.jar'
5. I have added into PATH (My Computer → Properties → Advanced → Environment Variables):
   ;C:\Program Files\Java\jre6\bin;C:\Program Files\Java\jre6\bin\server
6. I have restarted PostgreSQL service (postgresql-x64-9.3) and try to run this sql file through pgAdmin III - C:\Program Files\PostgreSQL\9.3\share\pljava\install.sql .

I got following error:
ERROR: could not load library "C:/Program Files/PostgreSQL/9.3/lib/pljava.dll": %1 is not a valid Win32 application.

********** Error **********

ERROR: could not load library "C:/Program Files/PostgreSQL/9.3/lib/pljava.dll": %1 is not a valid Win32 application.
SQL state: 58P01

Kindly help.

When compiling Java source with errors detected by the annotation processor, some of them are reported with the source line and column, but others are not. It seems to be ok for the ones that are checked directly in the mutators of annotation implementations, but the ones checked later in characterize have only their messages output, and no source location info. This smells a lot like that javac 7 behavior (see #39) where symbol table info gets thrown away between rounds.

The SQL generator generates an ordinary function declaration for a trigger function, with a parameter list (the one Java TriggerData parameter). That causes a Triggers can not have a java parameter declaration. error at runtime (not at function declaration time, because PL/Java doesn't have a validator entry point yet). The Triggers class in -examples did not contain code to actually test inserting something into the table and having the trigger successfully delivered, and as long as there is no validator, that's a necessary test.

Thanks to Petr Michálek for the report.

Hello,
I have an application that I developed with a PostgreSQL database 9.0, With Pl/Java stored procedures I want to know:

• what are the configurations to the target database
• How to backup restore
• how to load all jar files in the target database
• how to execute stored procedures in the target database

Thank you for your contribution.

This is a story that has to be pieced together out of commits and pulls, because there wasn't an issue filed (until now) to report the regression.

In August 2014, sptrakesh was working on Java 7 and clang support, and made a commit f49cf50 that commented pljava-examples out of the build in pom.xml, apparently because at least one example had stopped working.

In October 2014, fbroda made a commit bd6f79c that re-enabled pljava-examples and added an explicit complexType annotation to

@Function
Iterator<String> getProperties()

(and then a later commit 7b5f28d that corrected the complexType).

Apparently the regression was that Iterator<String> was no longer automatically recognized as RETURNS SETOF VARCHAR, as had been tested and known to work in Java 6.

The real problem is devilishly subtle and I'm not sure what to do about it yet. The annotation framework in javac calls the annotation processor in more than one "round" - we currently collect information about all the SQL-related annotations in the non-final round(s), then generate the DDR file in the final round.

What has started happening in Java 7 is that getElementUtils().getTypeElement(x) will always return the same TypeElement instance for a given name x within one round, but will now return a different TypeElement instance for the same type name x from one round to the next. Ultimately DDRProcessorImpl.TypeMapper.getSQLType ends up calling isAssignable(tm,ktm) to compare tm (java.lang.String from the Iterator type seen in earlier round) and ktm (java.lang.String mapped to VARCHAR, in current round), and isAssignable returns false because the two TypeElement instances representing java.lang.String are not the same!

I don't know if this is a Java 7 bug. Seems as if it might be ... at the very least, it is highly counterintuitive and seems likely to break stuff. I haven't stumbled easily on any other reports of it though.

I'm still looking at ways to get it working again. I'll add more when I learn more.

Meanwhile, there's kind of a moral in this issue. As pointed out in #11, at the moment the examples are about the nearest thing we have to regression testing. If at some point an example stops working, we need to report an issue to find out why it stopped working and solve the regression - not commit a change to the example that hides the problem (like the explicit annotation in this case). Hiding the problem in the example isn't going to stop anybody's real code from breaking in the same way. If it had been reported as an issue back in August 2014 there'd have been an extra year to get to the bottom of it.

The Wiki documentation for the build https://github.com/tada/pljava/wiki/Building-pl-java is outdated and describes the old makefile based build.

If I declare a function that takes no parameters, and call it with no parameters, I get the error "To many parameters - expected 0".

It doesn't seem to be just me:
http://code.google.com/p/salt-lake-county-earthquake/wiki/PLJavaStoredProcedure#Run_javaHelloWorld

The trouble seems to be right at the top of the for loop in Function.c / parseParameters(). I can see why it fails in this case, but I'm not sure I've understood everything it's supposed to be doing, so I should probably leave the fix to those who know the code better.

To pick on spelling, the word 'to' here should be 'too' (and there is another message "To few parameters" later in the file that should also be 'too').

Im trying to install pljava, when I clone de the repo and execute mvn compile, its fails cause a maven nar plugin problem, the important part of stack trace:
Caused by: org.apache.maven.plugin.MojoFailureException: NAR: Include path not found: com.github.maven_nar.IncludePath@6f94fb9d
at com.github.maven_nar.Compiler.getCompiler(Compiler.java:592)

My maven version is 3.0.5, java 8 and postgresql 9.3, in Ubuntu 14.04 64 bits

The current [http://wiki.tada.se PL/Java Wiki] should be moved over to GitHub and updated to reflect the new project location.

When writing a java method which returns SETOF something -- where something includes a UDT which is an enumeration, PLJava fails after returning. The problem seems to be the conversion of a String to the internal enum.

Stumbled on this while looking at a report by Ken Olson. The behavior of PostgreSQL's find_coercion_pathway function changed between 8.2 and 8.3 but PL/Java's Type.c still expects the old behavior.

I am struggling to install pljava on Windows 7 Sp1 with Postgres 9.4.

When I run the following command:
CREATE FUNCTION sqlj.java_call_handler()
RETURNS language_handler AS 'pljava'
LANGUAGE C;

I receive the following error:
ERROR: could not load library "C:/Program Files/PostgreSQL/9.4/lib/pljava.dll": The specified procedure could not be found.

From what I can tell this is due to the jvm.dll not being found by the system path, but i have the PATH variable set to C:\Program Files\Java\jre1.8.0_66\bin\server; which contains my jvm.dll file. What's more, I have run a sysinternals process monitor and can see the postgres,exe access the jvm.dll file when I run the code.

Additional items of interest:

1. i have updated the postgressql.conf file to have the following text in it:
   work_mem = 5MB
   pljava.classpath = 'C:\Program Files\PostgreSQL\9.4\lib\pljava.jar'
2. I have loaded the most current Windows 64 bit pljava.jar and pljava.dll files into the lib library referenced in the classpath above.

Any assistance will be welcome!

Again maybe I'm doing something wrong

I have installed using yum all packages of postgres

[root@localhost pljava]# yum list postgres*
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.uv.es
 * extras: mirror.uv.es
 * updates: mirror.uv.es
Installed Packages
postgresql94.x86_64                                                       9.4.5-1PGDG.rhel6                                           @pgdg94
postgresql94-contrib.x86_64                                               9.4.5-1PGDG.rhel6                                           @pgdg94
postgresql94-debuginfo.x86_64                                             9.4.5-1PGDG.rhel6                                           @pgdg94
postgresql94-devel.x86_64                                                 9.4.5-1PGDG.rhel6                                           @pgdg94
postgresql94-libs.x86_64                                                  9.4.5-1PGDG.rhel6                                           @pgdg94
postgresql94-plperl.x86_64                                                9.4.5-1PGDG.rhel6                                           @pgdg94
postgresql94-plpython.x86_64                                              9.4.5-1PGDG.rhel6                                           @pgdg94
postgresql94-pltcl.x86_64                                                 9.4.5-1PGDG.rhel6                                           @pgdg94
postgresql94-server.x86_64                                                9.4.5-1PGDG.rhel6                                           @pgdg94
postgresql94-test.x86_64                                                  9.4.5-1PGDG.rhel6                                           @pgdg94

Java mvn and gcc versions:

[root@localhost pljava]# java -version
java version "1.7.0_79"
Java(TM) SE Runtime Environment (build 1.7.0_79-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
[root@localhost pljava]# mvn -version
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T11:57:37+00:00)
Maven home: /usr/local/maven
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: /usr/java/jdk1.7.0_79/jre
Default locale: es_ES, platform encoding: UTF-8
OS name: "linux", version: "2.6.32-431.el6.x86_64", arch: "amd64", family: "unix"
[root@localhost pljava]# gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
Copyright (C) 2010 Free Software Foundation, Inc.
Esto es software libre; vea el código para las condiciones de copia.  NO hay
garantía; ni siquiera para MERCANTIBILIDAD o IDONEIDAD PARA UN PROPÓSITO EN
PARTICULAR

The output of pg_config

[root@localhost pljava]# pg_config 
BINDIR = /usr/pgsql-9.4/bin
DOCDIR = /usr/share/doc/pgsql
HTMLDIR = /usr/share/doc/pgsql
INCLUDEDIR = /usr/pgsql-9.4/include
PKGINCLUDEDIR = /usr/pgsql-9.4/include
INCLUDEDIR-SERVER = /usr/pgsql-9.4/include/server
LIBDIR = /usr/pgsql-9.4/lib
PKGLIBDIR = /usr/pgsql-9.4/lib
LOCALEDIR = /usr/pgsql-9.4/share/locale
MANDIR = /usr/pgsql-9.4/share/man
SHAREDIR = /usr/pgsql-9.4/share
SYSCONFDIR = /etc/sysconfig/pgsql
PGXS = /usr/pgsql-9.4/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--disable-rpath' '--prefix=/usr/pgsql-9.4' '--includedir=/usr/pgsql-9.4/include' '--mandir=/usr/pgsql-9.4/share/man' '--datadir=/usr/pgsql-9.4/share' '--with-perl' '--with-python' '--with-tcl' '--with-tclconfig=/usr/lib64' '--with-openssl' '--with-pam' '--with-gssapi' '--with-includes=/usr/include' '--with-libraries=/usr/lib64' '--enable-nls' '--with-uuid=e2fs' '--with-libxml' '--with-libxslt' '--with-ldap' '--with-system-tzdata=/usr/share/zoneinfo' '--sysconfdir=/etc/sysconfig/pgsql' '--docdir=/usr/share/doc' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et' 'CPPFLAGS= -I/usr/include/et'
CC = gcc
CPPFLAGS = -I/usr/include/et -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include
CFLAGS = -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/include/et
CFLAGS_SL = -fpic
LDFLAGS = -L../../../src/common -L/usr/lib64 -Wl,--as-needed
LDFLAGS_EX = 
LDFLAGS_SL = 
LIBS = -lpgcommon -lpgport -lxslt -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -lreadline -lrt -lcrypt -ldl -lm 
VERSION = PostgreSQL 9.4.5

and what i get when running mvn -X -e clean install

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] PostgreSQL PL/Java ................................. SUCCESS [  3.301 s]
[INFO] PL/Java API ........................................ SUCCESS [  6.712 s]
[INFO] PL/Java backend Java code .......................... SUCCESS [ 11.587 s]
[INFO] PL/Java backend native code ........................ FAILURE [  6.843 s]
[INFO] PL/Java Deploy ..................................... SKIPPED
[INFO] PL/Java Ant tasks .................................. SKIPPED
[INFO] PL/Java examples ................................... SKIPPED
[INFO] PL/Java packaging .................................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 30.889 s
[INFO] Finished at: 2015-11-11T11:16:17+00:00
[INFO] Final Memory: 26M/69M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.1.0:nar-compile (default-nar-compile) on project pljava-so: Execution default-nar-compile of goal com.github.maven-nar:nar-maven-plugin:3.1.0:nar-compile failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.github.maven-nar:nar-maven-plugin:3.1.0:nar-compile (default-nar-compile) on project pljava-so: Execution default-nar-compile of goal com.github.maven-nar:nar-maven-plugin:3.1.0:nar-compile failed.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-nar-compile of goal com.github.maven-nar:nar-maven-plugin:3.1.0:nar-compile failed.
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 20 more
Caused by: java.lang.NullPointerException
    at com.github.maven_nar.cpptasks.gcc.GppLinker.isClang(GppLinker.java:317)
    at com.github.maven_nar.cpptasks.gcc.GppLinker.addImpliedArgs(GppLinker.java:159)
    at com.github.maven_nar.cpptasks.compiler.CommandLineLinker.createConfiguration(CommandLineLinker.java:153)
    at com.github.maven_nar.cpptasks.compiler.AbstractLinker.createConfiguration(AbstractLinker.java:83)
    at com.github.maven_nar.cpptasks.ProcessorDef.createConfiguration(ProcessorDef.java:200)
    at com.github.maven_nar.cpptasks.CCTask.collectExplicitObjectFiles(CCTask.java:500)
    at com.github.maven_nar.cpptasks.CCTask.execute(CCTask.java:647)
    at com.github.maven_nar.NarCompileMojo.createLibrary(NarCompileMojo.java:433)
    at com.github.maven_nar.NarCompileMojo.narExecute(NarCompileMojo.java:107)
    at com.github.maven_nar.AbstractNarMojo.execute(AbstractNarMojo.java:329)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    ... 21 more
[ERROR] 
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :pljava-so
[root@localhost pljava]# 

Composite UDTs (and UDTs that mirror native PostgreSQL types) are registered by sqlj.add_type_mapping, but Base UDTs get registered in Function.c with the first call to one of their input/output/send/receive functions. That's all very well until a column of such a type is accessed in a way that doesn't call one of those first.

So, you can have:

# create table baz as select '(1,2)'::javatest.complex as z;
SELECT 1
postgres=# select javatest.logcomplex(z) from baz;
 logcomplex 
------------
 (1.0,2.0)
(1 row)

but start a clean session:

# \c
You are now connected to database "postgres"
postgres=# select javatest.logcomplex(z) from baz;
ERROR:  No java type mapping installed for "org.postgresql.pljava.example.annotation.ComplexScalar"

(Something like this should be added as a regression test some day when there is a better testing story; the need for a clean session rules out including it in the DDR.)

Two fix alternatives, neither one beautiful:

1. Declare that even base UDTs also need to be registered with sqlj.add_type_mapping. Almost works, but it turns out UDT_registerUDT takes an isJavaBasedScalar parameter, which is currently passed as always false by the code that finds entries in that map. Fixing that would require that code to examine the type much more closely to determine what kind of UDT it is, and that's roughly the same work as:
2. Add a test just before defaulting to String because no other mapping was found, and examine the type closely to see if it's a PL/Java UDT. Advantage: no need to fuss with add_type_mapping for base UDTs; disadvantage: it's a trail of many breadcrumbs from pg_type to a firm conclusion of PL/Java-UDT-ness.

Hello!
I downloaded project from https://github.com/tada/pljava .
Then try to package them. And get error on pljava-so module:

: [ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Cannot deduce version number from:

Apache Maven 2.2.1
Java version: 1.6.0_45

How to resolve this problem? Thanks in advance.

Hi,
pljava built for PG9.3 seems broken i.e.
ERROR: could not load library "/opt/pg/inst/lib/pljava.so": /opt/pg/inst/lib/pljava.so: undefined symbol: GETSTRUCT

pl/java source code require update and seems not compatible with PG 9.3. It seems that pl/java source code is moved to github but it don't build properly and gives errors start of the build i.e.
asif@uvm1:~/work/pljava$ make
make[1]: Entering directory /home/asif/work/pljava/build/classes/pljava' make[1]: /home/asif/work/pljava/src/java/pljava/Makefile: No such file or directory make[1]: *** No rule to make target/home/asif/work/pljava/src/java/pljava/Makefile'. Stop.
make[1]: Leaving directory `/home/asif/work/pljava/build/classes/pljava'
make: *** [pljava_all] Error 2

Related build instructions seems silent on it. For the time being I pulled latest source code from cvs.pgfoundry.org and made corrections to make it work for PG 9.3. PFA patch. It seems work fine now at least for install.sql, I did not tested it further yet i.e.

asif@uvm1:~/work/postgresql/postgresql/inst$ ./bin/psql -d postgres -p 8888 -c "select version();"

version

PostgreSQL 9.3beta2 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.4.4-14ubuntu5.1) 4.4.5, 64-bit
(1 row)
asif@uvm1:~/work/postgresql/postgresql/inst$ ./bin/psql -d postgres -p 8888 -f /home/asif/work/pljava/src/sql/install.sql
CREATE SCHEMA
GRANT
CREATE FUNCTION
CREATE LANGUAGE
CREATE FUNCTION
CREATE LANGUAGE
CREATE TABLE
GRANT
CREATE TABLE
GRANT
ALTER TABLE
CREATE TABLE
GRANT
CREATE TABLE
GRANT
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION

Changes done are required because of move of GETSTRUCT() and timeout handling framework changes done in PG 9.3. There little more effort required ( i.e to add #if (PGSQL_MAJOR_VER >= 93) ) to make it compatible with older version of PG. Please do let me know if I missed something or more info is required. Thanks.

I am not sure how to attach patch to this ticket/issue, I am pasting the patch as following, I hope that will help i.e.

asif$ cat pljava_9.3.patch.v1
? make.install.log
? make.log
? pljava_9.3.patch.v1_beta.v1
? pljava_9.3.patch.v1_beta.v2

Index: src/C/include/pljava/pljava.h

RCS file: /cvsroot/pljava/org.postgresql.pljava/src/C/include/pljava/pljava.h,v
retrieving revision 1.21
diff -p -r1.21 pljava.h
*** src/C/include/pljava/pljava.h 16 Apr 2010 09:25:10 -0000 1.21
--- src/C/include/pljava/pljava.h 2 Jul 2013 08:20:57 -0000
*************** extern int vsnprintf(char* buf, size_t c
*** 34,39 ****
--- 34,46 ----
#include <utils/memutils.h>
#include <tcop/tcopprot.h>

• /*

• * GETSTRUCT require "access/htup_details.h" to be included in PG9.3

• */

• #if (PGSQL_MAJOR_VER > 9 || (PGSQL_MAJOR_VER == 9 && PGSQL_MINOR_VER >= 3))

• #include "access/htup_details.h"

• #endif
  +
  /* The errorOccured will be set when a call from Java into one of the

  • backend functions results in a elog that causes a longjmp (Levels >= ERROR)

  • that was trapped using the PLJAVA_TRY/PLJAVA_CATCH macros.
    Index: src/C/pljava/Backend.c

    RCS file: /cvsroot/pljava/org.postgresql.pljava/src/C/pljava/Backend.c,v
    retrieving revision 1.93
    diff -p -r1.93 Backend.c
    *** src/C/pljava/Backend.c 30 Mar 2012 18:00:23 -0000 1.93
    --- src/C/pljava/Backend.c 2 Jul 2013 08:20:57 -0000

    ---

    *** 38,43 ****
    --- 38,48 ----
    #include "pljava/Session.h"
    #include "pljava/SPI.h"
    #include "pljava/type/String.h"
    +

• #if (PGSQL_MAJOR_VER > 9 || (PGSQL_MAJOR_VER == 9 && PGSQL_MINOR_VER >= 3))

• #include "utils/timeout.h"

• endif

  /* Example format: "/usr/local/pgsql/lib" */

  ifndef PKGLIBDIR

  error "PKGLIBDIR needs to be defined to compile this file."

  *************** static void _destroyJavaVM(int status, D
  *** 374,380 ****
  {
  Invocation ctx;

  if !defined(WIN32)

  ! pqsigfunc saveSigAlrm;

  Invocation_pushInvocation(&ctx, false);
  if(sigsetjmp(recoverBuf, 1) != 0)
  

  --- 379,385 ----
  {
  Invocation ctx;

  if !defined(WIN32)

  ! TimeoutId tid;

  Invocation_pushInvocation(&ctx, false);
  if(sigsetjmp(recoverBuf, 1) != 0)
  

  *************** static void _destroyJavaVM(int status, D
  *** 384,396 ****
  return;
  }

! saveSigAlrm = pqsignal(SIGALRM, terminationTimeoutHandler);
! enable_sig_alarm(5000, false);

    elog(DEBUG1, "Destroying JavaVM...");
    JNI_destroyVM(s_javaVM);

! disable_sig_alarm(false);
! pqsignal(SIGALRM, saveSigAlrm);
#else
Invocation_pushInvocation(&ctx, false);
elog(DEBUG1, "Destroying JavaVM...");
--- 389,401 ----
return;
}

! InitializeTimeouts(); /* establishes SIGALRM handler */
! tid = RegisterTimeout(USER_TIMEOUT, terminationTimeoutHandler);
! enable_timeout_after(tid, 5000);

    elog(DEBUG1, "Destroying JavaVM...");
    JNI_destroyVM(s_javaVM);

! disable_timeout(tid, false);
#else
Invocation_pushInvocation(&ctx, false);
elog(DEBUG1, "Destroying JavaVM...");

Chasing down (mostly) nuisance compiler warnings actually led to a non-nuisance! Here's a test for it. Fix committed in my compiler-warning-squashing branch, to be pushed shortly.

Pre-fix, this shows "works for 32767" and "fails for 32768" and all the larger values.
Post-fix, they all work. I can actually say select '1073741818'::utest; -- 1GB - 6 with
success, but it's slow so I didn't include that in the tests.

import java.sql.SQLData;
import java.sql.SQLException;
import java.sql.SQLInput;
import java.sql.SQLOutput;

import org.postgresql.pljava.annotation.SQLAction;
import org.postgresql.pljava.annotation.SQLActions;

@SQLActions({
  @SQLAction(install={
"  CREATE TYPE utest",
"  CREATE FUNCTION utest_in(cstring) RETURNS utest " +
"  AS 'UDT[utest] input' LANGUAGE java IMMUTABLE STRICT",
"  CREATE FUNCTION utest_out(utest) RETURNS cstring " +
"  AS 'UDT[utest] output' LANGUAGE java IMMUTABLE STRICT",
"  CREATE FUNCTION utest_recv(internal) RETURNS utest " +
"  AS 'UDT[utest] receive' LANGUAGE java IMMUTABLE STRICT",
"  CREATE FUNCTION utest_send(utest) RETURNS bytea " +
"  AS 'UDT[utest] send' LANGUAGE java IMMUTABLE STRICT",
"  CREATE TYPE utest ( " +
"    input = utest_in, " +
"    output = utest_out, " +
"    receive = utest_recv, " +
"    send = utest_send " +
"  )",
"  SELECT CASE v::text = v::utest::text " +
"   WHEN true THEN javatest.logmessage('INFO', 'works for ' || v) " +
"   ELSE javatest.logmessage('WARNING', 'fails for ' || v) " +
"   END " +
"   FROM (VALUES (('32767')), (('32768')), (('65536')), (('1048576'))) " +
"   AS t ( v )"
  }, remove="DROP TYPE utest CASCADE"
  )
})
public class utest implements SQLData {
  int apop = 73;

  public utest() { }

  public static utest parse(String s, String typname) {
    int i = Integer.parseInt( s);
    utest u = new utest();
    u.apop = i;
    return u;
  }

  public String toString() {
    return String.valueOf(apop);
  }

  public String getSQLTypeName() {
    return "utest";
  }

  public void writeSQL(SQLOutput stream) throws SQLException {
    for ( int i = 0 ; i < apop ; ++ i )
      stream.writeByte((byte)'a');
  }

  public void readSQL(SQLInput stream, String typname) throws SQLException {
    int i = 0;
    for ( ;; ++i )
      try {
        stream.readByte();
      }
      catch ( SQLException sqle ) {
        if ( "Unexpected EOF on data input".equals(sqle.getMessage()) )
          break;
        throw sqle;
      }
    apop = i;
  }
}

I have successfully built Pljava using maven on windows against PostgreSQL 9.3 (32 bit), using the latest pull request #29 (Fix to allow building pljava with Microsoft C). Thank you for that ! Everything is working except for.....

(6 lines of code)
java.sql.Connection sqlConnection = DriverManager.getConnection("jdbc:default:connection");
sql = "SELECT time_created FROM invoice_batch where id = " + batch.toString();
java.sql.ResultSet result = sqlConnection.createStatement().executeQuery(sql);
if (result.next()) {
createTimeStamp = result.getTimestamp("time_created");
}

.....where the result.getTimestamp crashes the JVM.

The log file generated by postgreSQL is included below. I think it has all java info needed!

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x006bf940, pid=5520, tid=1832

JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 1.7.0_80-b15)

Java VM: Java HotSpot(TM) Server VM (24.80-b11 mixed mode windows-x86 )

Problematic frame:

C [postgres.exe+0x2bf940]

Failed to write core dump. Minidumps are not enabled by default on client versions of Windows

If you would like to submit a bug report, please visit:

http://bugreport.java.com/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

--------------- T H R E A D ---------------

Current thread (0x0cb05400): JavaThread "main" [_thread_in_native, id=1832, stack(0x00860000,0x00c60000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x81d0270f

Registers:
EAX=0x00c5f0fc, EBX=0x55d476d0, ECX=0x00c5f0fc, EDX=0x00000000
ESP=0x00c5f0a8, EBP=0x00c5f0c8, ESI=0x81d025ff, EDI=0x0cb05400
EIP=0x006bf940, EFLAGS=0x00010202

Top of Stack: (sp=0x00c5f0a8)
0x00c5f0a8: 13338d20 13338d28 00000008 0c792e28
0x00c5f0b8: 00c5f0c8 5d758bf5 00c5f100 001c2db8
0x00c5f0c8: 00c5f0e0 006bfbe7 00c5f0fc 00000000
0x00c5f0d8: 00851c08 81d025ff 00c5f0f4 5d7624e3
0x00c5f0e8: 00c5f0fc 81d025ff 000f4240 00c5f104
0x00c5f0f8: 5d7624c6 55d476d0 00000000 00c5f13c
0x00c5f108: 5d7627b1 f6bcd6e8 0001c0a7 0000045a
0x00c5f118: 0d6e23e0 00c5f148 5d764e91 0000045a

Instructions: (pc=0x006bf940)
0x006bf920: e5 5d c3 cc cc cc cc cc cc cc cc cc cc cc cc cc
0x006bf930: 55 8b ec 83 ec 18 8b 45 08 53 8b 18 56 8b 75 14
0x006bf940: 83 be 10 01 00 00 00 57 8b 78 04 89 5d f0 89 7d
0x006bf950: f4 74 12 3b be 1c 01 00 00 7c 39 7f 08 3b 9e 18

Register to memory mapping:

EAX=0x00c5f0fc is pointing into the stack for thread: 0x0cb05400
EBX=0x55d476d0 is an unallocated location in the heap
ECX=0x00c5f0fc is pointing into the stack for thread: 0x0cb05400
EDX=0x00000000 is an unknown value
ESP=0x00c5f0a8 is pointing into the stack for thread: 0x0cb05400
EBP=0x00c5f0c8 is pointing into the stack for thread: 0x0cb05400
ESI=0x81d025ff is an unknown value
EDI=0x0cb05400 is a thread

Stack: [0x00860000,0x00c60000], sp=0x00c5f0a8, free space=4092k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [postgres.exe+0x2bf940]
C [postgres.exe+0x2bfbe7]
C [pljava.dll+0x124e3]
C [pljava.dll+0x124c6]
C [pljava.dll+0x127b1]
C [pljava.dll+0x12753]
C [pljava.dll+0x12722]
C [pljava.dll+0x14385]
C [pljava.dll+0x135e6]
C [pljava.dll+0x1369f]
j org.postgresql.pljava.internal.Tuple._getObject(JJI)Ljava/lang/Object;+0
j org.postgresql.pljava.internal.Tuple.getObject(Lorg/postgresql/pljava/internal/TupleDesc;I)Ljava/lang/Object;+15
j org.postgresql.pljava.jdbc.SPIResultSet.getObjectValue(I)Ljava/lang/Object;+9
j org.postgresql.pljava.jdbc.ObjectResultSet.getObject(I)Ljava/lang/Object;+2
j org.postgresql.pljava.jdbc.ObjectResultSet.getValue(ILjava/lang/Class;)Ljava/lang/Object;+3
j org.postgresql.pljava.jdbc.ObjectResultSet.getTimestamp(I)Ljava/sql/Timestamp;+5
j org.postgresql.pljava.jdbc.AbstractResultSet.getTimestamp(Ljava/lang/String;)Ljava/sql/Timestamp;+6
j rrapp.Main.exportInvoice(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/Integer;[Ljava/lang/Integer;Ljava/lang/String;)Ljava/lang/String;+209
v ~StubRoutines::call_stub
V [jvm.dll+0x15559a]
V [jvm.dll+0x224c3e]
V [jvm.dll+0x15561d]
V [jvm.dll+0xd7035]
V [jvm.dll+0xe049b]
C [pljava.dll+0xb6f4]
C [pljava.dll+0x14f17]
C [pljava.dll+0x14671]
C [pljava.dll+0x8aa6]
C [pljava.dll+0x220b]
C [pljava.dll+0x205e]
C [postgres.exe+0xda585]
C [postgres.exe+0xe6424]
C [postgres.exe+0xdf1e6]
C [postgres.exe+0xdf229]
C [postgres.exe+0xe6476]
C [postgres.exe+0xd8f59]
C [postgres.exe+0xd720c]
C [postgres.exe+0xd7f90]
C [postgres.exe+0x1d46a1]
C [postgres.exe+0x1d4cee]
C [postgres.exe+0x1d2d4b]
C [postgres.exe+0x1d3626]
C [postgres.exe+0x18f306]
C [postgres.exe+0x192d4d]
C [postgres.exe+0x104b91]
C [postgres.exe+0x2c6046]
C [kernel32.dll+0x1336a]
C [ntdll.dll+0x39882]
C [ntdll.dll+0x39855]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.postgresql.pljava.internal.Tuple._getObject(JJI)Ljava/lang/Object;+0
j org.postgresql.pljava.internal.Tuple.getObject(Lorg/postgresql/pljava/internal/TupleDesc;I)Ljava/lang/Object;+15
j org.postgresql.pljava.jdbc.SPIResultSet.getObjectValue(I)Ljava/lang/Object;+9
j org.postgresql.pljava.jdbc.ObjectResultSet.getObject(I)Ljava/lang/Object;+2
j org.postgresql.pljava.jdbc.ObjectResultSet.getValue(ILjava/lang/Class;)Ljava/lang/Object;+3
j org.postgresql.pljava.jdbc.ObjectResultSet.getTimestamp(I)Ljava/sql/Timestamp;+5
j org.postgresql.pljava.jdbc.AbstractResultSet.getTimestamp(Ljava/lang/String;)Ljava/sql/Timestamp;+6
j rrapp.Main.exportInvoice(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/Integer;[Ljava/lang/Integer;Ljava/lang/String;)Ljava/lang/String;+209
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
0x0c7cf000 JavaThread "Service Thread" daemon [_thread_blocked, id=2176, stack(0x5aa60000,0x5ae60000)]
0x0d981800 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=6652, stack(0x5a660000,0x5aa60000)]
0x0d980800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=4428, stack(0x5a260000,0x5a660000)]
0x0d46c800 JavaThread "Attach Listener" daemon [_thread_blocked, id=7116, stack(0x59e60000,0x5a260000)]
0x0c1ee000 JavaThread "Finalizer" daemon [_thread_blocked, id=4552, stack(0x59a60000,0x59e60000)]
0x0d58f400 JavaThread "Reference Handler" daemon [_thread_blocked, id=2188, stack(0x59660000,0x59a60000)]
=>0x0cb05400 JavaThread "main" [_thread_in_native, id=1832, stack(0x00860000,0x00c60000)]

Other Threads:
0x0d3b4000 VMThread [stack: 0x59260000,0x59660000] [id=5624]
0x0c60fc00 WatcherThread [stack: 0x5ae60000,0x5b260000] [id=6240]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
PSYoungGen total 19456K, used 12785K [0x41ac0000, 0x43040000, 0x57040000)
eden space 16896K, 60% used [0x41ac0000,0x424be838,0x42b40000)
from space 2560K, 99% used [0x42b40000,0x42dbdd18,0x42dc0000)
to space 2560K, 0% used [0x42dc0000,0x42dc0000,0x43040000)
ParOldGen total 43520K, used 84K [0x17040000, 0x19ac0000, 0x41ac0000)
object space 43520K, 0% used [0x17040000,0x170551d0,0x19ac0000)
PSPermGen total 16384K, used 3540K [0x13040000, 0x14040000, 0x17040000)
object space 16384K, 21% used [0x13040000,0x133b5170,0x14040000)

Card table byte_map: [0x0e4c0000,0x0e6f0000] byte_map_base: 0x0e427e00

Polling page: 0x03160000

Code Cache [0x10030000, 0x10270000, 0x13030000)
total_blobs=189 nmethods=56 adapters=88 free_code_cache=48736Kb largest_free_block=49884608

Compilation events (10 events):
Event: 0.317 Thread 0x0d981800 52 java.util.Properties$LineReader::readLine (452 bytes)
Event: 0.322 Thread 0x0d981800 nmethod 52 0x100950c8 code [0x10095200, 0x10095664]
Event: 0.326 Thread 0x0d980800 53 % java.lang.String::equals @ 49 (81 bytes)
Event: 0.329 Thread 0x0d980800 nmethod 53% 0x1008a708 code [0x1008a800, 0x1008aa70]
Event: 0.329 Thread 0x0d981800 54 java.lang.String::equals (81 bytes)
Event: 0.331 Thread 0x0d981800 nmethod 54 0x10092c88 code [0x10092d80, 0x10092f90]
Event: 0.335 Thread 0x0d980800 55 java.util.ArrayList::size (5 bytes)
Event: 0.335 Thread 0x0d980800 nmethod 55 0x10080348 code [0x10080440, 0x10080490]
Event: 0.335 Thread 0x0d981800 56 s! sun.misc.URLClassPath::getLoader (154 bytes)
Event: 0.347 Thread 0x0d981800 nmethod 56 0x1009b608 code [0x1009b7e0, 0x1009c5f4]

GC Heap History (2 events):
Event: 0.205 GC heap before
{Heap before GC invocations=1 (full 0):
PSYoungGen total 19456K, used 16886K [0x41ac0000, 0x43040000, 0x57040000)
eden space 16896K, 99% used [0x41ac0000,0x42b3d8b0,0x42b40000)
from space 2560K, 0% used [0x42dc0000,0x42dc0000,0x43040000)
to space 2560K, 0% used [0x42b40000,0x42b40000,0x42dc0000)
ParOldGen total 43520K, used 0K [0x17040000, 0x19ac0000, 0x41ac0000)
object space 43520K, 0% used [0x17040000,0x17040000,0x19ac0000)
PSPermGen total 16384K, used 1766K [0x13040000, 0x14040000, 0x17040000)
object space 16384K, 10% used [0x13040000,0x131f9aa0,0x14040000)
Event: 0.207 GC heap after
Heap after GC invocations=1 (full 0):
PSYoungGen total 19456K, used 2551K [0x41ac0000, 0x43040000, 0x57040000)
eden space 16896K, 0% used [0x41ac0000,0x41ac0000,0x42b40000)
from space 2560K, 99% used [0x42b40000,0x42dbdd18,0x42dc0000)
to space 2560K, 0% used [0x42dc0000,0x42dc0000,0x43040000)
ParOldGen total 43520K, used 84K [0x17040000, 0x19ac0000, 0x41ac0000)
object space 43520K, 0% used [0x17040000,0x170551d0,0x19ac0000)
PSPermGen total 16384K, used 1766K [0x13040000, 0x14040000, 0x17040000)
object space 16384K, 10% used [0x13040000,0x131f9aa0,0x14040000)
}

Deoptimization events (8 events):
Event: 0.157 Thread 0x0cb05400 Uncommon trap: reason=null_check action=make_not_entrant pc=0x10087580 method=java.util.jar.Attributes.putValue(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; @ 13
Event: 0.229 Thread 0x0cb05400 Uncommon trap: reason=unstable_if action=reinterpret pc=0x10082074 method=java.net.URL.(Ljava/net/URL;Ljava/lang/String;Ljava/net/URLStreamHandler;)V @ 170
Event: 0.230 Thread 0x0cb05400 Uncommon trap: reason=unstable_if action=reinterpret pc=0x1007b8c0 method=java.lang.String.replace(CC)Ljava/lang/String; @ 59
Event: 0.232 Thread 0x0cb05400 Uncommon trap: reason=unstable_if action=reinterpret pc=0x10077e8c method=java.lang.String.hashCode()I @ 14
Event: 0.247 Thread 0x0cb05400 Uncommon trap: reason=unstable_if action=reinterpret pc=0x100783f8 method=java.lang.String.indexOf([CII[CIII)I @ 3
Event: 0.252 Thread 0x0cb05400 Uncommon trap: reason=unstable_if action=reinterpret pc=0x1007e320 method=java.lang.String.equals(Ljava/lang/Object;)Z @ 66
Event: 0.282 Thread 0x0cb05400 Uncommon trap: reason=unstable_if action=reinterpret pc=0x100857dc method=java.lang.AbstractStringBuilder.append(Ljava/lang/String;)Ljava/lang/AbstractStringBuilder; @ 1
Event: 0.321 Thread 0x0cb05400 Uncommon trap: reason=unstable_if action=reinterpret pc=0x1007c398 method=java.util.StringTokenizer.scanToken(I)I @ 42

Internal exceptions (10 events):
Event: 0.331 Thread 0x0cb05400 Threw 0x423bb958 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319
Event: 0.331 Thread 0x0cb05400 Threw 0x423cb0c8 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319
Event: 0.333 Thread 0x0cb05400 Threw 0x423df780 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319
Event: 0.335 Thread 0x0cb05400 Threw 0x423efdb0 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319
Event: 0.336 Thread 0x0cb05400 Threw 0x42400e88 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319
Event: 0.337 Thread 0x0cb05400 Threw 0x4240fab8 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319
Event: 0.344 Thread 0x0cb05400 Threw 0x42431d48 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319
Event: 0.345 Thread 0x0cb05400 Threw 0x42436bb0 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319
Event: 0.349 Thread 0x0cb05400 Threw 0x4246c7a8 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319
Event: 0.349 Thread 0x0cb05400 Threw 0x42473e10 at C:\re\jdk7u80\2329\hotspot\src\share\vm\prims\jvm.cpp:1319

Events (10 events):
Event: 0.350 loading class 0x0d90b6e8
Event: 0.350 loading class 0x0d90b6e8 done
Event: 0.350 loading class 0x0d9278d8
Event: 0.350 loading class 0x0d9278d8 done
Event: 0.350 loading class 0x0d9277c8
Event: 0.350 loading class 0x0d9277c8 done
Event: 0.351 loading class 0x0ddbdb70
Event: 0.351 loading class 0x0d9270f8
Event: 0.351 loading class 0x0d9270f8 done
Event: 0.351 loading class 0x0ddbdb70 done

Dynamic libraries:
0x00400000 - 0x0085d000 c:\Program Files (x86)\postgreSQL\9.3\bin\postgres.exe
0x77a50000 - 0x77bd0000 C:\Windows\SysWOW64\ntdll.dll
0x75440000 - 0x75550000 C:\Windows\syswow64\kernel32.dll
0x75f10000 - 0x75f57000 C:\Windows\syswow64\KERNELBASE.dll
0x6d1b0000 - 0x6d1f8000 c:\Program Files (x86)\postgreSQL\9.3\bin\SSLEAY32.dll
0x6d080000 - 0x6d1a2000 c:\Program Files (x86)\postgreSQL\9.3\bin\LIBEAY32.dll
0x77610000 - 0x77645000 C:\Windows\syswow64\WS2_32.dll
0x77200000 - 0x772ac000 C:\Windows\syswow64\msvcrt.dll
0x76fc0000 - 0x770b0000 C:\Windows\syswow64\RPCRT4.dll
0x753c0000 - 0x75420000 C:\Windows\syswow64\SspiCli.dll
0x753b0000 - 0x753bc000 C:\Windows\syswow64\CRYPTBASE.dll
0x76160000 - 0x76179000 C:\Windows\SysWOW64\sechost.dll
0x76130000 - 0x76136000 C:\Windows\syswow64\NSI.dll
0x76e30000 - 0x76ec0000 C:\Windows\syswow64\GDI32.dll
0x76ec0000 - 0x76fc0000 C:\Windows\syswow64\USER32.dll
0x75be0000 - 0x75c81000 C:\Windows\syswow64\ADVAPI32.dll
0x75b30000 - 0x75b3a000 C:\Windows\syswow64\LPK.dll
0x759b0000 - 0x75a4d000 C:\Windows\syswow64\USP10.dll
0x6dd90000 - 0x6de4f000 C:\Windows\system32\MSVCR100.dll
0x6a300000 - 0x6a32b000 c:\Program Files (x86)\postgreSQL\9.3\bin\libintl.dll
0x6ade0000 - 0x6aee1000 c:\Program Files (x86)\postgreSQL\9.3\bin\libxml2.dll
0x73ca0000 - 0x73ca7000 C:\Windows\system32\WSOCK32.dll
0x6af10000 - 0x6aff4000 c:\Program Files (x86)\postgreSQL\9.3\bin\libiconv.dll
0x73c90000 - 0x73c98000 C:\Windows\system32\Secur32.dll
0x775c0000 - 0x77605000 C:\Windows\syswow64\WLDAP32.dll
0x76180000 - 0x761e0000 C:\Windows\system32\IMM32.DLL
0x755d0000 - 0x7569c000 C:\Windows\syswow64\MSCTF.dll
0x74fa0000 - 0x74fdc000 C:\Windows\system32\mswsock.dll
0x74f80000 - 0x74f85000 C:\Windows\System32\wshtcpip.dll
0x74f90000 - 0x74f96000 C:\Windows\System32\wship6.dll
0x10000000 - 0x10024000 c:\Program Files (x86)\postgreSQL\9.3\lib\plpgsql.dll
0x00e10000 - 0x00e3b000 c:\Program Files (x86)\postgreSQL\9.3\lib\pgcrypto.dll
0x63bb0000 - 0x63bc4000 c:\Program Files (x86)\postgreSQL\9.3\bin\zlib1.dll
0x5d750000 - 0x5d777000 c:\Program Files (x86)\postgreSQL\9.3\lib\pljava.dll
0x5c1f0000 - 0x5c7a4000 C:\Program Files (x86)\java\jdk1.7.0_80\jre\bin\server\jvm.dll
0x71ae0000 - 0x71b12000 C:\Windows\system32\WINMM.dll
0x772b0000 - 0x772b5000 C:\Windows\syswow64\PSAPI.DLL
0x6b4f0000 - 0x6b4fc000 C:\Program Files (x86)\java\jdk1.7.0_80\jre\bin\verify.dll
0x5d720000 - 0x5d741000 C:\Program Files (x86)\java\jdk1.7.0_80\jre\bin\java.dll
0x5d700000 - 0x5d713000 C:\Program Files (x86)\java\jdk1.7.0_80\jre\bin\zip.dll
0x5d6e0000 - 0x5d6f4000 C:\Program Files (x86)\Java\jdk1.7.0_80\jre\bin\net.dll
0x6a8c0000 - 0x6a8cf000 C:\Program Files (x86)\Java\jdk1.7.0_80\jre\bin\nio.dll
0x74e90000 - 0x74f7b000 C:\Windows\system32\dbghelp.dll

VM Arguments:
jvm_args: -Djava.endorsed.dirs=C:\RRSQL\jar\endorsed -Dhttp.proxyHost=cache.road-runner.net -Dhttp.proxyPort=8081 -Dhttp.nonProxyHosts=localhost|127.0.0.1|soap.ned -Dsqlj.defaultconnection=jdbc:default:connection vfprintf -Xrs
java_command:
Launcher Type: generic

Environment Variables:
JAVA_HOME=C:\Program Files (x86)\java\jdk1.7.0_80
PATH=C:\apache-maven-3.3.3\bin;C:\MinGW\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Intel\DMIX;C:\Program Files (x86)\CVSNT;C:\Program Files (x86)\Liant\RMCOBOLv11;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\GtkSharp\2.12\bin;c:\Program Files (x86)\postgreSQL\9.3\bin;C:\Program Files (x86)\java\jdk1.7.0_80\jre\bin;C:\Program Files (x86)\java\jdk1.7.0_80\jre\bin\server;c:\Program Files\Saxonica\SaxonHE9.4N\bin
USERNAME=Paul Brasted
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 37 Stepping 2, GenuineIntel

--------------- S Y S T E M ---------------

OS: Windows 7 , 64 bit Build 7601 Service Pack 1

CPU:total 4 (2 cores per cpu, 2 threads per core) family 6 model 37 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, aes, ht, tsc, tscinvbit

Memory: 4k page, physical 8181064k(4373440k free), swap 16360288k(12290552k free)

vm_info: Java HotSpot(TM) Server VM (24.80-b11) for windows-x86 JRE (1.7.0_80-b15), built on Apr 10 2015 13:27:32 by "java_re" with unknown MS VC++:1600

time: Wed Aug 19 12:30:08 2015
elapsed time: 0 seconds

hope you don't mind starting up a discussion on pljava for macosx. I have postgresql 9.3 installed in macosx 10.9 Mavericks. the database is installed in /Library/PostgreSQL/9.3/data standard install. I am trying to get pljava running on mac (darwin). Do you have a complete procedure for getting this installed?

The current build script uses an overly restrictive regular expression to parse
the output of pg_config --version. It fails if PostgreSQL was built with the --with-extra-version
option that adds to the end of the string. It also fails for EnterpriseDB builds that add a fourth
numeric component.

Reported by Daniel Westermann.

Hello,

I'm trying to build the pljava from the source on windows with PostgreSQL 9.2, but i couldn't find any document talking about that. Please I need a document with a clear instructions to build pljava on windows and PostgreSQL 9.2, or if it's possible to share the pljava binaries if anyone has it.

Please help me.

Avain is A lightweight alternative to Java, it's better than GCJ.

I believe PL/java is killing unicode characters (it is probably converting text to a byte stream and reading them as single byte characters - perhaps Latin-1 and not as UTF-8). I don't observe this happening with PL/Python or PL/R.

I basically have a record which looks like the attached image

When I invoke a PL/Java function to simply read this input text field and return it as is, i noticed that the unicode characters are lost. The attached image shows the result.

Here is my PL/java function and the corresponding java snippet.

    PL/Java Function

drop function if exists demo.returnString(text) cascade;
create function demo.returnString(text)
returns text
as 
    'demopkg.Example.returnString'
immutable language pljavau;

    Java Snippet (in class demopkg.Example)

    public static String returnString(String tweet) {
    if (tweet == null) {
        return null;
    }
    Writer writer = null;

    try {
        writer = new BufferedWriter(new OutputStreamWriter(
              new FileOutputStream("/tmp/pljava_out.txt"), "utf-8"));
        writer.write("Tweet\n");
        writer.write(tweet);
    } catch (IOException ex){
      // report
    } finally {
       try {writer.close();} catch (Exception ex) {}
    }
    return tweet;
}

 Here is how I am invoking the SQL

select tweet_body, 
       demo.returnString(tweet_body) pljava_result,
       demo.dummy(tweet_body) plpython_result
from demo.training_data
where id = 'tag:search.twitter.com,2005:356830788370706433'

The file that I am writing out to in the java code (/tmp/pljava_out.txt) shows that the unicode chars have already been lost (i don't see the emoticons in the file). So the error is occurring even before the function returns - perhaps during the postgres type to java type conversion.

Things I have tried to debug

1. My database is UTF-8
2. The "file.encoding" property also returns UTF-8 (when I invoke the PL/java function to return the property).
3. The "LOCALE" settings on my machine is also UTF-8.
4. The problem only occurs with PL/java (PL/Python and PL/R return the string alright).
5. Exhausted Google to search for this, but there is only one other user who has reported it and there is no resolution. Here is the related thread: http://lists.pgfoundry.org/pipermail/pljava-dev/2008/001385.html

The pom.xml file of the pljava-so project contains some code that performs a copy of the pljava.so into it's final destination in /usr/lib (or /usr/lib64). It executes during the deploy phase which is unfortunate since that phase normally uploads the artifact to its remote repository.

The declaration has been commented out (by me) since it prevents the actual deploy phase from performing the upload. It also required root privileges to run. We need to find an alternative approach to installing that file under /usr.

@tada/pl-java-contributors

Hello.

I get an error:
ERROR: no se pudo cargar la biblioteca «C:/Program Files/PostgreSQL/9.2/lib/pljava.dll»: unknown error 126

Has anybody else seen this error?

My setup:
Windows 7 Pro;PostgreSQL 9.2.4, compiled by Visual C++ build 1600, 64-bit;
java version "1.7.0_17"

JAVA_HOME = "C:\Program Files\Java\jre7"

PATH = %JRE_HOME%\bin;%JRE_HOME%\bin\client

Consider a function that returns SETOF RECORD (perhaps because its arguments determine what exact columns it returns). To use it, you need an AS clause at the callsite so the proper result TupleDesc can be set up:

SELECT * from myInfo( '{firstname,middlename,lastname}') AS (first text, middle text, last text);

What happens if you are careless and call this function without an AS clause? A null pointer dereference in type/Composite.c in _Composite_getTupleDesc() segfaults the backend and everybody gets kicked out of PostgreSQL.

I'm pretty sure the first switch case in that function just needs to test td for null before trying to dereference it to tdtypeid, and ereport "missing context (try AS?)" if it's null.

EDIT: I misdescribed the problem at first. If you only forget the AS clause, the SQL parser catches it, and you get this message: a column definition list is required for functions returning "record".

To get the segfault requires two things: a missing AS clause, and not calling the function in FROM position:

SELECT myInfo('{firstname,middlename,lastname}');

And the fix here does correct that; now you get the newly added "try AS?" message in that case.

Follow the suggestion from issue 63 (tried all branches same issue) - I believe that I could build it with Issue 63 branch with postgres 9.4.5 but unfortunately I upgraded to postgres 9.5 no data for that scenario with postgres 9.4.5.

cd pljava-so
mvn -Dnar.cores=1 -Pwnosign -X clean comple>compiledebuglogs

compiledebugwithpgconfig.zip

I managed to build pljava [[https://github.com/fbroda/pljava/tree/jdk7]] under openSUSE 13.1 (x86_64) for JDK 1.7 (Oracle JavaSE 1.7.0.71) and PostgreSQL 9.3.5 using forks from @sptrakesh and @gdmSISouth. Especially the nar-maven-plugin gave me a hard time (release 3.1.0 works, 3.2.0 doesn't work for me). I made a mess, because I didn't read the guidelines for contributors early and carefully (therefore I started in branch master and continued in ill-named branch jdk7).

There are still some issues with pljava-examples but I currently can't tell exactly what needs to be fixed there. The simpler stuff seems to work though.

Anyway, I would like to see support for JDK 1.7 in PL/Java. If I need to fix / polish / whatever my branch, before it's ready for integration into the master repository, I could possibly spend a few hours.

We must add junit based regression tests to the Maven build. I think the simplest way to do this is to turn the current examples into JUnit tests and then use the maven-failsafe-plugin to establish an integration test suite that essentially:

1. Drops existing test-database
2. Creates a new test-database
3. Installs PL/Java into the new test-database
4. Installs test functions into the new test-database
5. Runs the JUnit tests

It takes hours to build sometimes because of this:
loading: http://nexus.tada.se/content/repositories/releases/org/apache/maven/plugins/maven-install-plugin/maven-metadata.xml
Downloading: http://nexus.tada.se/content/repositories/snapshots/org/apache/maven/plugins/maven-install-plugin/maven-metadata.xml
[WARNING] Could not transfer metadata org.apache.maven.plugins:maven-install-plugin/maven-metadata.xml from/to releases.tada.se (http://nexus.tada.se/content/repositories/releases/): Failed to transfer f.
[WARNING] Could not transfer metadata org.apache.maven.plugins:maven-install-plugin/maven-metadata.xml from/to snapshots.tada.se (http://nexus.tada.se/content/repositories/snapshots/): Failed to transfer.
Downloading: ht

This patch adds support for PostgreSQL 9.5 by adding a required parameter:
https://gist.github.com/mc-soi/34d980feeb92f8208dfb

A #if (PG_VERSION_NUM >= 90500) might be needed to make this code also compile with earlier versions.

On Solaris 10, /bin/sh does not accept $() syntax, which is used in the mvn launch script, but bash is available and can be used explicitly to run the script: instead of mvn clean install, use bash path/to/mvn clean install.

The built-in aol.properties file in the nar-maven-plugin does not have entries for Solaris with gpp. A supplementary file can be named on the command line with -Dnar.aolProperties=.

The stack size limit may need to be enlarged, as already described for 32-bit builds.

Reported by Eugenie V. Lyzenko.

$ make
make[1]: /Users/peisentraut/devel/github/pljava/pljava/src/java/pljava/Makefile: No such file or directory
make[1]: *** No rule to make target `/Users/peisentraut/devel/github/pljava/pljava/src/java/pljava/Makefile'.  Stop.
make: *** [pljava_all] Error 2

Apparently some files were moved around the makefile not updated.

Hello,
I developed an application with PostgreSQL 9.0 as database and i use, with stored procedures Pl / java (in windows xp os). everything went smoothly. But when I deployed this application in another machine (Windows Server 2008).
None of these stored procedures are running, they returned me the following error:

ERREUR: Unable to find static method Rh.Groupe.f_save_groupe with signature (ILjava/lang/String;)I
ERREUR: Unable to find static method Parametrage.Ville.f_findAll_ville with signature ()Lorg/postgresql/pljava/ResultSetProvider;

I do everything but without success.

before recovering my database, I make the following configurations:

• In postgreSQL 9.0 (postgresql.conf file)

dynamic_library_path = '$libdir'(I did not set up because I put the pljava.dll file in lib )

pljava.classpath = 'C:\Program Files\PostgreSQL\9.0\lib\pljava.jar;C:\Program Files\PostgreSQL\9.0\lib\Mission.jar;C:\Program Files\PostgreSQL\9.0\lib\lib\postgresql-9.1-901.jdbc4.jar;'

custom_variable_classes = 'pljava'

log_min_messages = info

• PATH environment
  JRE_HOME= C:\Program Files\Java\jre7
  path= %JRE_HOME%\bin;%JRE_HOME%\bin\client
• Installing my . Jar file in PostgreSQL 9.0
  SELECT sqlj.install_jar('file:///Program Files/PostgreSQL/9.0/lib/Mission.jar', 'Mission ', true);

SELECT sqlj.install_jar('file:///Program Files/PostgreSQL/9.0/lib/pljava.jar', 'pljava ', true);

SELECT sqlj.set_classpath('public', 'Mission');
SELECT sqlj.set_classpath('sqlj', 'Mission');

But in the end I found that the content of table sqlj.typemap_entry is empty .

Thank you for bring me your support

I have made considerable investment into pljava backend with postgresql and am stuck on
9.1 because the binary is not distributed any more .

I am presuming I have to build pljava.dll and that pljava.jar can be used from the postgres 9.1 installation.
I presume that the source is C and so have cygwin and the latest gcc.
I am able to donwload the relavant postgres source.

Will someone please give me line by line instructions to build this dll

Thanks

Please add support for PostgreSQL 9.4. Thanks!

Need tools to assist in the installation of pljava.

Here is a first go at requirements gathering. Please discuss.

some pljava installation requirements

• check environment and pre-reqs
  • is postgreSQL server installed, which version?
  • java jre 1.6+
  • is pljava installed, which version - sufficient to inspect extension directory on 9.1+? How to determine whether pljava is installed pre v9.1 w/o package manager help?
• use pg_config to query for information
• copy pljava shared lib to correct location (e.g. pg_config --pkglibdir)
  • server version must match major.minor version shared lib was compiled with
• modify postgresql.conf, adding pljava.* entries
  • note: v9.2 no longer allows custom_variable_classes property
• install extension files for postgreSQL 9.1+ (pg_config --sharedir/extension/...)

questions

• What is preferred tool(s) for install tasks - one or more of shell script, ant, gradle, something else? I listed java build/deploy tools I know of since it's a java-related product.
• Are there preferred distribution type(s)? tar|zip bundles; rpm|deb packages?
• Presume there is only one version of postgreSQL installed on server?
• Probably not feasible to interact with running postgreSQL server? Perhaps provide post-install instructions (e.g. use deploy.jar or 'create extension') in INSTALL file and print same after pljava install task runs?
• Where is correct location for pljava shared lib? (libdir || pkglibdir)? Answer: --pkglibdir is correct choice
• Is there a sure-fire way to find postgresql.conf in use (esp. if server isn't running)?
• Will artifacts be available on maven central?
• what are target versions of postgresSQL server, priorities? Probably 'supported' versions - curerntly 8.4 to 9.2
• target operating systems, priorities?

(Editing this issue for context; the reporter began it on the end of a different issue #94. -Chap)

(This is OS X El Capitan, 10.11.3. After building 1.5.0-BETA1 and setting config variables as follows)

pljava.libjvm_location='/Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/server/libjvm.dylib'
pljava.classpath='/usr/local/share/postgresql/pljava/pljava-1.5.0-BETA1.jar'

(The following popup is reported to appear, even though pljava.libjvm_location explicitly refers to an installation of Java 8.)

(otool shows the following libraries coded into the pljava bundle):

otool -L /usr/local/lib/postgresql/libpljava-so-1.5.0-BETA1.bundle 
/usr/local/lib/postgresql/libpljava-so-1.5.0-BETA1.bundle:
    /usr/local/opt/postgresql/lib/libecpg.6.dylib (compatibility version 6.0.0, current version 6.7.0)
    /usr/local/opt/postgresql/lib/libpgtypes.3.dylib (compatibility version 3.0.0, current version 3.6.0)
    /usr/local/opt/postgresql/lib/libpq.5.dylib (compatibility version 5.0.0, current version 5.8.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

(There should not be any reference to a different JVM coded in, and there is not, so that is as it should be.)

I try to many times, but its not working..

CentOS / 64bits
Java JRE 1.6
Response from PostgreSQL 9.3:

could not load library "/usr/pgsql-9.3/lib/pljava.so": /usr/pgsql-9.3/lib/pljava.so: undefined symbol: disable_sig_alarm

Env Vairables:

$JRE_HOME=/usr/java/jre
$LD_LIBRARY_PATH=$JRE_HOME/lib/amd64:$JRE_HOME/lib/amd64/server

PostgreSQL.conf
pljava.classpath='/usr/pgsql-9.3/share/pljava/pljava.jar'

Do you know that problem on PostgreSQL 9.3 ?

Hello,
During installation of pl / java in PostgreSQL,
I want to know when will the tables of sqlj schema are filled,particularly ff table
sqlj.typemap_entry .

We need a mechanism whereby we can add database migration scripts. Issues like #10 makes changes to the database that are not backward compatible and any environment that wishes to upgrade must have an easy path forward.

Function looks up methods using JNI_getStaticMethodIDOrNull which discards all exceptions so that Function can try other mungings of the signature to find a match.

That's great, only NoSuchMethodError isn't the only exception that can happen there. In particular, getStaticMethodID can cause class initialization, and if there's a bug in any initializer (a common enough possibility), the exception gets lost and instead of any hint what the real problem is, the dev is left puzzling over a "Method not found" message when the method is obviously there.

Better for JNI_getStaticMethodIDOrNull to discard the exception only if it really is NoSuchMethodError and let any other exception propagate.

I am attempting to install PL/JAVA against PG v9.4 running on CentOS x64 with the 1.8 JDK.

I have downloaded the .gz; expanded it... and have run the following command:

java -cp {path to jdbc.jar}:{path to deploy.jar} -Djava.library.path=$JAVA_HOME/jre/lib org.postgresql.pljava.deploy.Deployer -install -user {superuser} -password {superuser password}

And I am getting the following error:

org.postgresql.util.PSQLException: ERROR: could not access file "pljava": No such file or directory

Discovered by Dave Cramer. That'd be mine. The issue 21 Unicode patch requires more initialization for String.c, used in exception reporting, and the exception if pljava.jar can't be found comes before that happens.

Pull request #59 had a note in passing that the supplied Point example (a Java UDT that mirrors a PostgreSQL native type) was broken, with Java seeing values very different from what PostgreSQL saw. Not diagnosed at the time, but turns out if I had been running on big-endian hardware, there would have been no problem.

The raw-memory-chunk-based SQLInput and SQLOutput implementations (and only those; the ones for composite types are not affected) have used a fixed, big-endian byte order, from inception in 1.3.0 up to and including 1.5.0-BETA2. It doesn't obtrude as a problem for purely Java-based base UDTs because nothing but Java touches them, but when a UDT mirrors a PostgreSQL-visible type and the hardware is little-endian, of course it's conspicuously broken.

Even for pure-Java base UDTs, where it has not heretofore obtruded as a problem, it would be made instantly very obtrusive by any fix that just rashly changed the byteorder to native; any existing columns holding data of those types would become bogus. So a fix would need to introduce a byte-order configuration knob, and a sensible way to do migration.