On 8-Sep-05, at 2:18 AM, Thomas Hallgren wrote:
Peter Eisentraut wrote:
Thomas Hallgren wrote:
Well, yes. But use the word environment in singular please :-) To my
knowledge the security is full-proof with all other VM's since they
all use the standard runtime libraries.
It's not quit
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Doesn't this make it hard for distributions to package up a language in a
> rpm (or some other system) and have it just work?
No, it makes it easier. Particularly when you think about altering the
implementation details of that language across succes
"Rupa Schomaker (lists)" <[EMAIL PROTECTED]> writes:
> Situation: A user installs a third-party PL that installs itself by
> updating the template catalog and then doing a createlang.
> Can the user simply do a dumpall/restore and get back into working
> order. Or will the user have to re-run the
On Thu, 8 Sep 2005, Tom Lane wrote:
> I've committed the changes to have a system catalog in place of the
> hard-wired table. In the initial commit, I listed only the languages
> included in the core distribution.
If I understand this correct you have created a system table that contain
the sett
On 9/8/2005 9:20 PM, Tom Lane wrote:
> "Rupa Schomaker (lists)" <[EMAIL PROTECTED]> writes:
>
>>How are dumps/restores of local modifications to the template going to
>>be handled?
>
>
> pg_dump has no business trying to save or restore the template data;
> if it did so then we'd just have moved
"Rupa Schomaker (lists)" <[EMAIL PROTECTED]> writes:
> How are dumps/restores of local modifications to the template going to
> be handled?
pg_dump has no business trying to save or restore the template data;
if it did so then we'd just have moved the original problem of obsolete
data to a differe
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Thomas Hallgren wrote:
>> PL/Java is designed to run perfectly safe with a JVM that has the
>> correct features implemented. GCJ has serious issues with security
>> and I don't see that PL/Java, nor PostgreSQL should make any attempt
>> to fix them.
>
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> That's great news for PL/Java (and for Java in general of course). Did
> they mention a release date?
You can have it today if you feel like downloading Fedora Rawhide.
(Actually you might want to wait till tomorrow -- I hear rawhide is
pretty borked
On 8-Sep-05, at 3:45 PM, Thomas Hallgren wrote:
Tom Lane wrote:
Actually, I've just been discussing this with Red Hat's gcj people in
connection with a different project. What they say is that the Java
security manager is completely implemented now, but what is still
missing is that it's pos
I wrote:
> Well, that's exactly the point Peter is arguing: he thinks (if I
> understand correctly) that the template mechanism should only be used
> for stuff that's included with the core distribution. I disagree;
> I have seldom seen any good reason for restricting mechanisms to work
> with onl
Peter Eisentraut wrote:
The way I was reading your statements was that you concluded from this
sitation that GCJ should not be used at all for real work.
I see your point and my way of expressing it was probably too harsh. I
agree that there are many applications where an unsafe VM can be sa
Tom Lane wrote:
Actually, I've just been discussing this with Red Hat's gcj people in
connection with a different project. What they say is that the Java
security manager is completely implemented now, but what is still
missing is that it's possible to bypass Java security if you can execute
unt
Thomas Hallgren wrote:
> >Frankly, that is all FUD.
>
> No, that's all facts.
Those two are not mutually exclusive.
> We where discussing a very specific situation here. Not GCJ in
> general. As you pointed out yourself (and that's what started this
> discussion), GCJ cannot be used for a trusted
Peter Eisentraut wrote:
Thomas Hallgren wrote:
GCJ currently that has limited security. It is 2 years behind
mainstream in versions (they don't have Java 5 yet and their Java 1.4
support is not complete). It is not stable and the performance is
nowhere close to the commercial implementations
Thomas Hallgren wrote:
> GCJ currently that has limited security. It is 2 years behind
> mainstream in versions (they don't have Java 5 yet and their Java 1.4
> support is not complete). It is not stable and the performance is
> nowhere close to the commercial implementations.
Frankly, that is all
Well don't forget sablevm, and jamvm. there's quite a few around.
Dave
On 8-Sep-05, at 9:48 AM, Thomas Hallgren wrote:
Dave Cramer wrote:
Actually the apache guys are doing another one (Harmony), and
there is Kaffe. Hardly relevant to the conversation, just added
for completion
I st
On 8-Sep-05, at 2:18 AM, Thomas Hallgren wrote:
Peter Eisentraut wrote:
Thomas Hallgren wrote:
Well, yes. But use the word environment in singular please :-) To my
knowledge the security is full-proof with all other VM's since they
all use the standard runtime libraries.
It's not
Dave Cramer wrote:
Actually the apache guys are doing another one (Harmony), and there
is Kaffe. Hardly relevant to the conversation, just added for completion
I stand corrected. I forgot Kaffe. It also uses the "classpath" stuff
and have the same issues as GCJ.
Isn't Harmony is just an incu
Peter Eisentraut wrote:
Thomas Hallgren wrote:
Well, yes. But use the word environment in singular please :-) To my
knowledge the security is full-proof with all other VM's since they
all use the standard runtime libraries.
It's not quite as simple as that. There are a bunch of VMs a
Greg Stark <[EMAIL PROTECTED]> writes:
> I'm not sure how that relates to the template work you're
> discussing. Are all of the templates you're creating for components
> that are built out of core and therefore can be expected to be
> packaged?
Well, that's exactly the point Peter is arguing: he
Tom Lane <[EMAIL PROTECTED]> writes:
> Now this certainly discriminates against installing PLs outside $libdir,
> but I haven't heard any good reason why people would need to do that.
Well one example would be distributions that package up some PLs but want to
allow you to install some on your o
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In any case, "java" has not been put forward as one of the template
>> entries, and as long as we don't accept a template for it, we have
>> not made the situation any worse.
> Hmm, Thomas Hallgren sent in a template using "java" as
Tom Lane wrote:
> (What the PL template approach *would* do is make it difficult to
> create a language that is trusted but named pljavau, or untrusted and
> named pljava.
But the latter is exactly what I would like to do.
> Personally I don't see that as a bad thing, however.
> The opportunity
Tom Lane wrote:
> Are you seriously suggesting that it's a good idea for the single
> language name "java" to mean different things at different
> installations? I can't believe that that wouldn't lead to chaos.
There is a standard for the SQL integration of a "java" language, and I
don't see wh
Thomas Hallgren wrote:
> Well, yes. But use the word environment in singular please :-) To my
> knowledge the security is full-proof with all other VM's since they
> all use the standard runtime libraries.
It's not quite as simple as that. There are a bunch of VMs and a bunch
of libraries (and a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In any case, not one of these arguments seems to me to favor the
>> alternative of preloading definitions into pg_language:
> That is not the alternative I am proposing. Your template idea,
> hard-coded even, is just fine for core
Tom Lane wrote:
> Now this certainly discriminates against installing PLs outside
> $libdir, but I haven't heard any good reason why people would need to
> do that.
Development, testing, staging, ...
> > If I have PL/foo 1.0
> > installed and upgrade from PostgreSQL 8.0 to 8.1, the validator in
>
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> GCJ is a clean house implementation of Java. They don't use the runtime
> libraries from Sun and they are not really there yet in their efforts to
> copy the functionality. One of the things that lag behind is security.
> They hope to have a better s
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The case in reality is this: First of all, the language name "java" is
> fixed by the SQL standard, so we ought to allow alternative
> implementations to use that name. I'm not sure what kind of interface
> the PL/J people are working on, but if t
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
The other problem I see emerging here is that in certain environments,
the "java" language may not be trusted, such as when it is compiled
with GCJ.
Well, yes. But use the word environment in singular please :-) To my
knowle
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We know we have a problem with hard-coded paths
>> in old dumps.
> This is irrelevant for non-core languages. If I have PL/foo 1.0
> installed and upgrade from PostgreSQL 8.0 to 8.1, then I have to
> manually recompile PL/foo an
Tom Lane wrote:
> But it's exactly the same hole the user would create by manually
> saying CREATE TRUSTED LANGUAGE in error. I don't think that's a
> reasonable argument against the template idea --- it just says that
> you have to be aware of what you're doing.
>
> (An appropriate solution, in m
Tom Lane wrote:
> These are straw men.
No, these are real problems that exist today.
> We know we have a problem with hard-coded paths
> in old dumps.
This is irrelevant for non-core languages. If I have PL/foo 1.0
installed and upgrade from PostgreSQL 8.0 to 8.1, then I have to
manually rec
Tom Lane wrote:
> > How is this different from
>
> > 1. register language in pg_language without privileges
> > 2. activate language by granting privileges
>
> Because you can't create a language without first creating the support
> procedures, which ordinarily requires having the shared library
>
Tom Lane wrote:
> Barring further changes, we'll have a hard-wired template list for
> 8.1 and a real system catalog in 8.2. So there's a choice now for
> PLs that are not part of the core distribution: do you want to be
> listed in the hard-wired template?
Another note: PLs that are not in the c
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> We are only talking about well-known procedural languages. The issue of
> completely new languages added by the user is addressed by neither
> proposal.
Sure it is: in my proposal, you can add new languages to the template
catalog. (Which admitted
I wrote:
> Another note: PLs that are not in the core distribution are not
> created with createlang in the first place, so the issues that led up
> to this proposal don't apply AFAICT,
What I'm trying to say here is that it might be OK to hardcode the
properties of core languages in the server,
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The other problem I see emerging here is that in certain environments,
> the "java" language may not be trusted, such as when it is compiled
> with GCJ.
Hmm, is that really the case? I thought Java is Java.
> Then, this built-in template will over
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> What I'm trying to say here is that it might be OK to hardcode the
> properties of core languages in the server, because considering that
> the only officially supported way to activate those is
> "createlang" (rather than using SQL), the properties
Thomas Hallgren wrote:
> If my assumptions are correct, then please add:
>
> { "java", true, "sqlj.java_call_handler", NULL,
> "libpljava" },
> { "javaU", false, "sqlj.javau_call_handler", NULL,
> "libpljava" },
In the interest of uniformity, please rename y
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Wouldn't it be better if all PL's used the
> dynamic_library_path setting at all times?
I wouldn't think so at all. That's just another way to shoot yourself
in the foot; $libdir is the correct place by definition, and any other
directory is not the
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
I assume that the path of the shared library will be somehow relative to
the GUC dynamic_library_path?
Well, whatever you put in the template is what will be in the probin
field of the support functions. I suppose it does no
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I assume that the path of the shared library will be somehow relative to
> the GUC dynamic_library_path?
Well, whatever you put in the template is what will be in the probin
field of the support functions. I suppose it does not *have* to use
$libdir,
Tom,
I assume that the path of the shared library will be somehow relative to
the GUC dynamic_library_path? If not, the lanlibrary should be changed
to "$libdir/libpljava". That requires that PL/Java is installed within
the PostgreSQL distribution.
I also assume that the handler name can be p
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> So your proposal is to enable a new language by doing:
> 1. register a template
> 2. activate template using CREATE LANGUAGE (which would copy it to
> pg_language)
That's the long-term idea, yes.
> How is this different from
> 1. register language
Tom Lane wrote:
> I don't see it as an exception list. The direction I see for this is
> that the parameters to CREATE LANGUAGE are obsolete and will
> eventually be removed altogether, with "CREATE LANGUAGE foo" using an
> existing template as the only recommended way to do it.
So your proposal
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Anyway, clearly there are cases where a validator make no sense or
very little sense (pl/sh and pl/{j,java} spring to mind).
PL/sh has a validator. :-)
Really? Curious. I must look more closely.
cheers
andrew
---
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't doubt that, but I just have a stomach ache with this entire
> notion of having a hard-coded exception list of the sort "if the user
> requires this, do this instead".
I don't see it as an exception list. The direction I see for this is
that
Tom Lane wrote:
> There is deliberately not a way to override (other than using a
> different name for the PL). One of the points of this facility is to
> fix up broken PL definitions being imported from old dump files, so
> believing what the CREATE LANGUAGE command says is exactly what we
> don'
Andrew Dunstan wrote:
> Anyway, clearly there are cases where a validator make no sense or
> very little sense (pl/sh and pl/{j,java} spring to mind).
PL/sh has a validator. :-)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
Tom Lane wrote:
For instance, if you think you might want a validator later,
you can set up a no-op validator procedure today, and then the template
doesn't need to change when you make the validator do something.
Similarly, you could future-proof yourself against adding a trusted (or
untruste
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Is there any way to create the language and not use the template (an
> override option of some kind)?
There is deliberately not a way to override (other than using a
different name for the PL). One of the points of this facility is to
fix up broken
Tom Lane wrote:
> Barring further changes, we'll have a hard-wired template list for
> 8.1 and a real system catalog in 8.2. So there's a choice now for
> PLs that are not part of the core distribution: do you want to be
> listed in the hard-wired template?
Is there any way to create the language
Tom Lane wrote:
If you want to be listed, let me know. What I need to know to list you
is values for this table:
typedef struct
{
char *lanname; /* PL name */
boollantrusted; /* trusted? */
char *lanhandler; /* name of handler function */
ch
I've committed changes to implement the cut-down form of this proposal:
http://archives.postgresql.org/pgsql-hackers/2005-08/msg01185.php
discussed here:
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00138.php
Barring further changes, we'll have a hard-wired template list for 8.1
and a r
55 matches
Mail list logo
