Does anyone has a solution for pljava.dll not loading? I see the same issue
listed
for 8.3-rc1, supposedly fixed in 8.3-rc3. But I need something that works
for
8.2
C:\Program Files\PostgreSQL\8.2\bin>"%JAVA_HOME%/bin/java" -cp
../../../../pljav
a-i686-pc-mingw32-pg8.2-1.3.1/deploy.jar;../jdbc/po
On Mon, 14 Jan 2008, Josh Berkus wrote:
Juergen,
Is a pljava.dll for version 8.2.6 out?
It's very important for me, need it for my office.
Try e-mailing pgsql-jdbc mailing list and asking there.
The correct list is actually [EMAIL PROTECTED] The JDBC driver
and the server side languag
Juergen,
Is a pljava.dll for version 8.2.6 out?
It's very important for me, need it for my office.
Try e-mailing pgsql-jdbc mailing list and asking there.
--Josh
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Hi there,
as you now is plJava broken with the actual security releases.
There is a pljava.dll at http://www.ejurka.com/pgsql/pljava/83rc1/ to
fix it for version 8.3RC1.
Is a pljava.dll for version 8.2.6 out?
It's very important for me, need it for my office.
Juergen
--
On 11/01/2008, Kris Jurka <[EMAIL PROTECTED]> wrote:
> Turns out it's not just 83RC1, but all of the security releases, which
> will require different pljava packages for the patch versions before/after
> the security changes. I've committed a fix to CVS for this, and I guess
> I'll try to respin
On Thu, 10 Jan 2008, Tom Lane wrote:
Just out of curiosity, what was pljava doing calling SetUserId?
If I'd known about that I'd have thought harder about removing the
function; but it's not clear to me why a PL should be doing that.
pljava wants to run code as the session user when inside
Kris Jurka <[EMAIL PROTECTED]> writes:
> Turns out it's not just 83RC1, but all of the security releases, which
> will require different pljava packages for the patch versions before/after
> the security changes.
Just out of curiosity, what was pljava doing calling SetUserId?
If I'd known about
On Thu, 10 Jan 2008, Kris Jurka wrote:
On Thu, 10 Jan 2008, Jan Ischebeck wrote:
8.3beta3 and 4 have worked perfectly with the provided pljava ddl, just
with 8.3-rc1 it doesn't work anymore.
8.3RC1 changed the function definition for SetUserId, so pljava needs
some changes and a rebuild.
On Thu, 10 Jan 2008, Jan Ischebeck wrote:
8.3beta3 and 4 have worked perfectly with the provided pljava ddl, just
with 8.3-rc1 it doesn't work anymore.
8.3RC1 changed the function definition for SetUserId, so it pljava needs
some changes and a rebuild. Will fix.
Kris Jurka
Hi,
I'm following the 8.3 beta releases for some time now, mostly using the
Win32 with Installer package.
8.3beta3 and 4 have worked perfectly with the provided pljava ddl, just
with 8.3-rc1 it doesn't work anymore.
i.e.
1. automatic installation of Pl/Java via Installer fails.
2. manual
"Bruce Momjian" <[EMAIL PROTECTED]> wrote in message
> It seems this would be handled just like we handle C functions today,
> that is you create a shared object file, it sits in the file system, and
> you LOAD the object into your backend, or you record it via CREATE
> FUNCTION and specify the pat
Thomas Hallgren wrote:
> Hi,
> I've made some very encouraging tests using The GNU version of Java known as
> GCJ together with my Pl/Java implementation . At present I use GCJ just like
> any other JVM, i.e. as an interpreter. This is not very optimal since GCJ
> can compile all Java code into sha
Hi,
I've made some very encouraging tests using The GNU version of Java known as
GCJ together with my Pl/Java implementation . At present I use GCJ just like
any other JVM, i.e. as an interpreter. This is not very optimal since GCJ
can compile all Java code into shared libraries just like it would
On Mon, Feb 23, 2004 at 05:14:09PM +0100, Peter Eisentraut wrote:
> Thomas Hallgren wrote:
> > 1. Select Pl/Java_JNI.
> > 2. Select Pl/Java_remote
> > 3. Choose both and agree on the SQL + Java semantics
> > 4. Make the postmaster spawn threads rather than processes
> > (controversial? Nah :-) )
>
Tom Lane wrote:
> "Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> > ** 4. Make the postmaster spawn threads rather than processes **
> > I know this is very controversial and perhaps I should not bring it up at
> > all. But then again, why not? Most readers are open-minded right?
>
> It's been con
Hi all!
Sorry for my latencies.
An IRC chat is ok for me, anytime.
On Sun, Feb 22, 2004 at 08:08:00PM +0100, Thomas Hallgren wrote:
> I'm in Sweden. Some time tuesday evening (european time) perhaps?
>
> Why is your work not made public somewhere? The project on sourceforge is
> inactive it seem
> On the re-use front it would be VERY nice if you could
> somehow have a single patch for PostgreSQL's C code that called a set of
> Java interfaces. Then each of your implementations could implement that
set
> of Java interfaces (one using JNI, the other using RMI). This would allow
> the user
Hello all,
>
> 3. Probe deeper and see if there's more that we can share (C-code
> essentially).
> I have my doubts about sharing C-code since we do things fundamentally
> different. I know you have a generic call mechanism that we could use to
> establish a common ground, but I think it would bad
Thomas Hallgren
- Original Message -
From: "Dave Cramer" <[EMAIL PROTECTED]>
To: "HORNYAK Laszlo" <[EMAIL PROTECTED]>
Cc: "Thomas Hallgren" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, February 23, 2004 13:41
Subject: Re: [HACKERS]
> Option 5 (or 0) would be to use GCJ. This is likely to be the fastest
> and most lightweight solution, but perhaps not the most featureful.
>
GCJ is definitely an alternative for the reasons you mention. I didn't
mention it (nor any other JVM) because I see it as one of several "JVM's"
that Pl/J
Thomas Hallgren wrote:
> 1. Select Pl/Java_JNI.
> 2. Select Pl/Java_remote
> 3. Choose both and agree on the SQL + Java semantics
> 4. Make the postmaster spawn threads rather than processes
> (controversial? Nah :-) )
Option 5 (or 0) would be to use GCJ. This is likely to be the fastest
and mos
tues evening euro time is fine with me. I am at GMT-5 so it will be
afternoon for me. What time ?
We should attempt an agenda?
Dave
On Sun, 2004-02-22 at 15:33, HORNYAK Laszlo wrote:
> Hi all!
>
> Sorry for my latencies.
> An IRC chat is ok for me, anytime.
>
> On Sun, Feb 22, 2004 at 08:08:00P
One perfectly good reason for this scenario is portability between
postgres and any database implementing the standard (e.g. Oracle).
cheers
andrew
Dave Cramer wrote:
Not to minimize your work, as I think it is great, but this particular
use-case I consider to be overkill for pl/java. It is pr
I'm in Sweden. Some time tuesday evening (european time) perhaps?
Why is your work not made public somewhere? The project on sourceforge is
inactive it seems. Do you have a CVS setup privately?
> Not to minimize your work, as I think it is great, but this particular
> use-case I consider to be ov
Not to minimize your work, as I think it is great, but this particular
use-case I consider to be overkill for pl/java. It is probably easier to
use pl/pgsql if all you want to do is calculations.
We had suggested an online chat to discuss this, when would you be
available for that? What timezone a
> 1) Using JNI, you probably still want to communicate with another
> running java process.
B.T.W. I don't really agree on "probably". There are numerous cases when you
will be happy just communicating with the database, communicate with another
remote resource (message queue typically), or not co
Hi Dave,
Comments on your comments inline...
> What I would like to see is an abstraction of the interface that
> communicates with the JVM so that we can use either, as you have pointed
> out the JNI mechanism has advantages, as does the remote mechanism.
>
Yes, we must agree 100% on the "interf
Thomas,
What I would like to see is an abstraction of the interface that
communicates with the JVM so that we can use either, as you have pointed
out the JNI mechanism has advantages, as does the remote mechanism.
I recently did an analysis of the two methods and there are a couple of
other poi
Thomas Hallgren wrote:
That's an interesting thougth. The postmaster just forks. It never exec's
right? Is this true for win32 as well? I've never tried it but it might be
worth pursuing. Sun's new Java 1.5 jvm does this albeit a bit differently.
An initializer process starts up and persists its st
Thomas Hallgren wrote:
Other than that fear, though, the JNI approach seems to have pretty
considerable advantages. You listed startup time as the main
disadvantage, but perhaps that could be worked around. Suppose the
postmaster started a JVM --- would that state inherit correctly into
subseq
> It's been considered and rejected before, and pljava isn't going to tilt
> the scales.
>
Didn't think it would. Thought it worth mentioning anyway, partly to get
your reaction.
> In fact, the main thing that bothers me about your
> description of JNI is "Java uses multithreading wether you like
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> ** 4. Make the postmaster spawn threads rather than processes **
> I know this is very controversial and perhaps I should not bring it up at
> all. But then again, why not? Most readers are open-minded right?
It's been considered and rejected before,
Two Pl/Java implementations exists today. Due to the architecture of
PostgreSQL, compromises have been made in both of them to deal with the fact
that each connection lives in its own process. One, I'll call it
"Pl/Java_JNI" will spawn a JVM on demand for each connection and the other,
"Pl/Java_rem
The Pl/Java project that I'm working on is progressing quite nicely. The
beta release that I just uploaded to GBorg at
http://gborg.postgresql.org/project/pljava/projdisplay.php has most of the
functionality that I have intended for the first stable release. If you are
interested, please take a loo
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Will we need to address this TODO item:
. Add capability to create and call PROCEDURES
before proceding to do PL/Java? It would add to the usefulness
greatly, I should think. I'm not sure how hard it would be.
This should be relatively easy
Andrew Dunstan wrote:
> Will we need to address this TODO item:
>
> . Add capability to create and call PROCEDURES
>
> before proceding to do PL/Java? It would add to the usefulness
> greatly, I should think. I'm not sure how hard it would be.
This should be relatively easy if you omit OUT param
I'm working on a pl/java project and have come quite far with it. Triggers
and Functions are both callable, there's support for complex types etc. I
have a project on GBorg (pljava) where I'll post all source in a CVS
repository in a matter of days (the code is ready but my ISP have a router
proble
Joe Conway said:
> Andrew Dunstan wrote:
>> AFAIK it is not available except for $$$. It looks like the relevant
>> standards are parts 1 and 2 of the SQLJ standard (Part 0 covers
>> embedded SQL).
>>
>
> For working drafts try:
>
> http://www.wiscorp.com/sql/sql_2003_standard.zip
> (5WD-13-JRT-200
Dave Cramer said:
> Can you explain what you mean by this?
>
> On Fri, 2004-01-02 at 20:21, Andrew Dunstan wrote:
>> Will we need to address this TODO item:
>>
>> . Add capability to create and call PROCEDURES
>>
>> before proceding to do PL/Java? It would add to the usefulness
>> greatly, I sho
Barry,
Ok, so if we drop this limitation then we leave it up to the architect
to manage the caching problem themselves.
The class loader issue is interesting, this would mean that each object
static or otherwise would not be able to overwrite others data.
--dc--
On Wed, 2003-12-31 at 19:34, Barr
Can you explain what you mean by this?
Dave
On Fri, 2004-01-02 at 20:21, Andrew Dunstan wrote:
> Will we need to address this TODO item:
>
> . Add capability to create and call PROCEDURES
>
> before proceding to do PL/Java? It would add to the usefulness greatly,
> I should think. I'm not sur
Andrew Dunstan wrote:
AFAIK it is not available except for $$$. It looks like the relevant
standards are parts 1 and 2 of the SQLJ standard (Part 0 covers embedded
SQL).
For working drafts try:
http://www.wiscorp.com/sql/sql_2003_standard.zip
(5WD-13-JRT-2003-09.pdf)
http://www.wiscorp.com/sql/sql
Will we need to address this TODO item:
. Add capability to create and call PROCEDURES
before proceding to do PL/Java? It would add to the usefulness greatly,
I should think. I'm not sure how hard it would be.
cheers
andrew
---(end of broadcast)-
Dave Cramer wrote:
Barry,
Ok, so if we drop this limitation then we leave it up to the architect
to manage the caching problem themselves.
Maybe I don't understand enough about Java, but isn't this limitation
(only static methods callable) exactly what avoids having to deal with
the call->insta
Dave Cramer said:
> Where is the standard, I for one would be interested in seeing it?
>
AFAIK it is not available except for $$$. It looks like the relevant
standards are parts 1 and 2 of the SQLJ standard (Part 0 covers embedded
SQL).
cheers
andrew
---(end of broadca
Where is the standard, I for one would be interested in seeing it?
Dave
On Fri, 2004-01-02 at 01:09, Andrew Dunstan wrote:
> Jan Wieck wrote:
>
> > The basic question is the definition of the lifetime of an object and
> > it's identificaition when doing nested calls in this context. In the
> >
Jan Wieck wrote:
The basic question is the definition of the lifetime of an object and
it's identificaition when doing nested calls in this context. In the
OO world, ideally a real world object is translated into one instance
of a class. And complex structures are trees of instances, possibly
Barry,
This appears in principal to be very close to a servlet container. I'm
wondering if we could just use something like jetty as the basis for the
work?
It has already defined class loading per the servlet spec. It is already
setup to handle multiple requests, and load balancing, etc.
Dave
Barry,
Ok, so if we drop this limitation then we leave it up to the architect
to manage the caching problem themselves.
The class loader issue is interesting, this would mean that each object
static or otherwise would not be able to overwrite others data.
--dc--
On Wed, 2003-12-31 at 19:34, Barr
Jan,
In Oracle a call from sql into java (be it trigger, stored procedure or
function), is required to be a call to a static method. Thus in Oracle
all the work is left for the programmer to manage object instances and
operate on the correct ones. While I don't like this limitation in
Oracle
Jan Wieck wrote:
> As an example, if a PL/Java trigger on the order header executes an SPI
> query on the order lines, a trigger on the order line (also in PL/Java)
> might now want to call a method on it's parent object (the order header
> that is waiting for the SPI result set). This should NO
I have included the JDBC mailing list since I guess most Java developers
are around here, but not necessarily on Hackers.
Dave Cramer and I where discussing a few issues about the PL/Java
implementation last night and would like to get more input and
suggestions on the matter.
The basic questi
Hi All!
Is anyone else working on
pl/java?
We are still working on it. In a few weeks we may
have a testable version. (For the most fearless hackers, we have a test
version now :)
If anyone else is working on any implementation,
please contect us!
http://pljava.sourceforge.net/
Thank
53 matches
Mail list logo
