Joshua D. Drake wrote:
I find the whole argument that, lack of an untrusted version of the PL
means it should be deprecated, crazy. There are plenty of situations
where you don't care that the PL is untrusted.
Yes you are absolutely correct. However my argument was more than that.
Right.
Dave,
Some responses inline. As a reaction to what Josh just wrote - "Keep in
mind that for us non-Java geeks most of your argument is pure ancient
Greek" - I'll try to talk in generic terms from now on and not mention
Java since the difference between our solutions have nothing whatsoever
to
Thomas, Dave,
I did *NOT* want to start another discussion about what approach is
superior. Keep in mind that for us non-Java geeks most of your argument
is pure ancient Greek.
What I wanted to establish is: potentially, we will have two Java PLs with
Postgres. If we do, we need to have a
On 17-Aug-05, at 12:40 PM, Thomas Hallgren wrote:
Andrew Dunstan wrote:
Dave Cramer wrote:
As there are two java procedural languages which are available
for postgreSQL Josh asked for an explanation as to their
differences.
They are quite similar in that both of them run the function in
I find the whole argument that, lack of an untrusted version of the PL
means it should be deprecated, crazy. There are plenty of situations
where you don't care that the PL is untrusted.
Yes you are absolutely correct. However my argument was more than that.
It contained:
The fact that it w
Andrew Dunstan wrote:
Dave Cramer wrote:
As there are two java procedural languages which are available for
postgreSQL Josh asked for an explanation as to their differences.
They are quite similar in that both of them run the function in a
java vm, and are pre-compiled. Neither attempt to
Dave Cramer wrote:
As there are two java procedural languages which are available for
postgreSQL Josh asked for an explanation as to their differences.
They are quite similar in that both of them run the function in a
java vm, and are pre-compiled. Neither attempt to compile the code.
Th
As there are two java procedural languages which are available for
postgreSQL Josh asked for an explanation as to their differences.
They are quite similar in that both of them run the function in a
java vm, and are pre-compiled. Neither attempt to compile the code.
The biggest difference is
On Tue, Aug 16, 2005 at 01:46:26PM -0700, David Fetter wrote:
> On Tue, Aug 16, 2005 at 11:39:04PM +0300, Marko Kreen wrote:
> > On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote:
> > > If somebody has figured out a way to make a PL/Python (without the
> > > U), that's great, but nothing
Josh Berkus wrote:
People:
How about we draft some criteria for inclusion of a PL in the main distro?
Suggestions:
1) The PL must be "stable" (that is, not capable of crashing the backend)
Check. (well, a more humble statement is perhaps to say that any bug
that would cause a crash would be c
David Fetter wrote:
On Tue, Aug 16, 2005 at 01:17:27PM -0400, Gregory Maxwell wrote:
I promise that the aggregate work required for all coders who know
Python to switch to ruby is far far greater than the work required
to fix the issues with pl/python. :)
Are you certain? See above in re: wh
Josh Berkus schrieb:
People:
How about we draft some criteria for inclusion of a PL in the main distro?
Suggestions:
1) The PL must be "stable" (that is, not capable of crashing the backend)
2) The PL must be buildable only using --with-{lang} and createlang
(assuming that the user has the co
As with an automatic weapon, Perl absolutely *requires* discipline to
use properly. Unlike an automatic weapon, Perl is perfectly OK to use
day-to-day in civilian life :)
What on earth would be the proper use of an automatic weapon?
You obviously don't live in the US.
Yeah, "hunting"...
There are two questions, I perceive, critical to making decisions
about what goes into the core. While I'm not a contributing developer,
I've worked with PostgreSQL since it was still Stonebraker's child and
still use Postquel, and have rolled it inot a lot of production
situations, so I'm going t
People:
How about we draft some criteria for inclusion of a PL in the main distro?
Suggestions:
1) The PL must be "stable" (that is, not capable of crashing the backend)
2) The PL must be buildable only using --with-{lang} and createlang
(assuming that the user has the correct libraries)
3) The
This seems to have descended into a "my programming language is better
than your programming language" war, which has ceased to be
interesting, much less illuminating to the problem at hand.
There are two questions, I perceive, critical to making decisions
about what goes into the core. While I'm
Alvaro Herrera said:
> On Tue, Aug 16, 2005 at 02:14:46PM -0700, David Fetter wrote:
>
>> As with an automatic weapon, Perl absolutely *requires* discipline to
>> use properly. Unlike an automatic weapon, Perl is perfectly OK to use
>> day-to-day in civilian life :)
>
> What on earth would be the
Alvaro Herrera wrote:
On Tue, Aug 16, 2005 at 02:14:46PM -0700, David Fetter wrote:
As with an automatic weapon, Perl absolutely *requires* discipline to
use properly. Unlike an automatic weapon, Perl is perfectly OK to use
day-to-day in civilian life :)
What on earth would be the proper u
On Tue, Aug 16, 2005 at 02:14:46PM -0700, David Fetter wrote:
> As with an automatic weapon, Perl absolutely *requires* discipline to
> use properly. Unlike an automatic weapon, Perl is perfectly OK to use
> day-to-day in civilian life :)
What on earth would be the proper use of an automatic wea
On Tue, Aug 16, 2005 at 05:09:24PM -0400, Gregory Maxwell wrote:
> On 8/16/05, David Fetter <[EMAIL PROTECTED]> wrote:
> > It's not. In PL/parlance, "trusted" means "prevented from ever
> > opening a filehandle or a socket," and PL/PythonU is called
> > PL/Python*U* (U for *un*trusted) because it
On 8/16/05, David Fetter <[EMAIL PROTECTED]> wrote:
> It's not. In PL/parlance, "trusted" means "prevented from ever
> opening a filehandle or a socket," and PL/PythonU is called
> PL/Python*U* (U for *un*trusted) because it cannot be so prevented.
>
> If somebody has figured out a way to make a
On T, 2005-08-16 at 09:14 -0700, Joshua D. Drake wrote:
> > Is there a sound reason to believe that pl/Ruby does not have the
> > trusted/untrusted issue ?
>
> Sure... it hasn't been found.
"It hasn't been found" is a really weak reason for any security
assumption, even for a programming language
On Tue, Aug 16, 2005 at 11:39:04PM +0300, Marko Kreen wrote:
> On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote:
> > If somebody has figured out a way to make a PL/Python (without the
> > U), that's great, but nothing has happened on this front in a
> > couple of years, and Guido said t
On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote:
> If somebody has figured out a way to make a PL/Python (without the U),
> that's great, but nothing has happened on this front in a couple of
> years, and Guido said that it was a problem with the language that he
> wasn't going to fix.
Joshua D. Drake wrote:
Most distributions of Linux (yes I know that there is more than Linux
out there) don't ship with Java. They ship with a wanna be, but couldn't
be in the next 2 years thing call Gcj.
Gcj is OK with PL/Java, albeit slower then the more common JVM's from
Sun, IBM, or BEA.
On Tue, Aug 16, 2005 at 01:17:27PM -0400, Gregory Maxwell wrote:
> On 8/16/05, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > Sure... it hasn't been found. We can play the it "might have" or
> > "might not have" game all day long but it won't get us anywhere.
> > Today, and yesterday pl/Ruby can be
David Fetter wrote:
On a very closely related note, what's the latest on the integration
of PL/Java and PL/J?
Last time I spoke to Laszlo and Dave about this, we discussed the
following solution:
- PL/Java should be profiled as a "tight Java integration", i.e. Java
executes in the same VM
Dave Cramer wrote:
Well, if we are going to consider pljava for the main distribution,
then we should consider pl-j for inclusion as well.
I believe we should consider both but only include 1.
Sincerely,
Joshua D. Drake
Dave
On 16-Aug-05, at 11:53 AM, Josh Berkus wrote:
Folks,
I thi
On 8/16/05, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> Sure... it hasn't been found. We can play the it "might have" or "might
> not have" game all day long but it won't get us anywhere. Today, and
> yesterday pl/Ruby can be run trust/untrusted, pl/python can not.
> > Both of these things could b
Joshua,
There's some material that explains the inner workings on the
gborg.postgresql.org/project/pljava site. Beyond that (and trying it out
of course), I'd be more then happy to answer any questions.
Regards,
Thomas Hallgren
Joshua D. Drake wrote:
I think you should take a closer look
Well, if we are going to consider pljava for the main distribution,
then we should consider pl-j for inclusion as well.
Dave
On 16-Aug-05, at 11:53 AM, Josh Berkus wrote:
Folks,
I think you should take a closer look at PL/Java for the following
reasons:
Hmmm, this brings up a good po
Josh Berkus wrote:
Folks,
I think you should take a closer look at PL/Java for the following reasons:
Hmmm, this brings up a good point. If we're going to consider PL/Ruby for
main distro in 8.2, should we not consider PL/Java as well?
There is one strong reason other than that, I have
I think you should take a closer look at PL/Java for the following reasons:
1. The number of followers of the Java language is extremely high and
increasing.
2. Oracle and DB2 offers Java as a procedural language. You make
transisitions easy.
3. There's a SQL standard for the mapping between
Is there a sound reason to believe that pl/Ruby does not have the
trusted/untrusted issue ?
Sure... it hasn't been found. We can play the it "might have" or "might
not have" game all day long but it won't get us anywhere. Today, and
yesterday pl/Ruby can be run trust/untrusted, pl/python can
Folks,
> I think you should take a closer look at PL/Java for the following reasons:
Hmmm, this brings up a good point. If we're going to consider PL/Ruby for
main distro in 8.2, should we not consider PL/Java as well?
--
Josh Berkus
Aglio Database Solutions
San Francisco
--
Dave Cramer wrote:
On 15-Aug-05, at 1:30 PM, Joshua D. Drake wrote:
Hello,
I have negotiated with the author of pl/Ruby to release plRuby under
the PostgreSQL license. The reason I did this is the following:
1. I felt we needed a truly OO language in core.
Why ? Are you truly going t
On 15-Aug-05, at 1:30 PM, Joshua D. Drake wrote:
Hello,
I have negotiated with the author of pl/Ruby to release plRuby
under the PostgreSQL license. The reason I did this is the following:
1. I felt we needed a truly OO language in core.
Why ? Are you truly going to write huge OO function
Joshua D. Drake wrote:
Hello,
I have negotiated with the author of pl/Ruby to release plRuby under the
PostgreSQL license. The reason I did this is the following:
What does everybody think?
I think you should take a closer look at PL/Java for the following reasons:
1. The number of followe
On E, 2005-08-15 at 10:30 -0700, Joshua D. Drake wrote:
> Hello,
>
> I have negotiated with the author of pl/Ruby to release plRuby under the
> PostgreSQL license.
Good!
> The reason I did this is the following:
>
> 1. I felt we needed a truly OO language in core.
> 2. plPython isn't really m
Am Montag, den 15.08.2005, 10:30 -0700 schrieb Joshua D. Drake:
> Hello,
>
> I have negotiated with the author of pl/Ruby to release plRuby under the
> PostgreSQL license. The reason I did this is the following:
>
> 1. I felt we needed a truly OO language in core.
> 2. plPython isn't really movi
Bruce Momjian wrote:
I do think plruby would be a nice addition to core.
Me too. It needs some work (didn't build out of the box for me against
cvs tip).
FYI, I have a backburner project to create PL/JS, which would a
trusted-only language - JS could actually be quite a nice fit, and
Bruce Momjian wrote:
I do think plruby would be a nice addition to core. I also assume this
is for the 8.2 release, not 8.1.
Yes that would be my assumption as well.
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replicatio
I do think plruby would be a nice addition to core. I also assume this
is for the 8.2 release, not 8.1.
---
Joshua D. Drake wrote:
> >
> > Hmm. I read this as
> >
> > Problem: not enough hackers to maintain our PL l
Hmm. I read this as
Problem: not enough hackers to maintain our PL languages.
Proposed solution: add more PL languages.
Somehow this doesn't seem quite right.
Although I see your point, that actually wasn't my point. My point was
that I felt we need a good well respected
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I have negotiated with the author of pl/Ruby to release plRuby under the
> PostgreSQL license. The reason I did this is the following:
> 1. I felt we needed a truly OO language in core.
> 2. plPython isn't really moving forward and has the whole
>
45 matches
Mail list logo