Message-ID: <44296E24.5010602@tada.se>
Date: Tue, 28 Mar 2006 19:11:00 +0200
From: Thomas Hallgren <thomas@tada.se>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Simon Riggs <simon@2ndquadrant.com>,
	Martijn van Oosterhout <kleptog@svana.org>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	PL/Java Development <Pljava-dev@gborg.postgresql.org>
Subject: Re: Shared memory
References: <4423CF32.3060406@tada.se> <20060324125851.GC8718@svana.org>
	<4427A8F1.3020009@tada.se> <14559.1143473507@sss.pgh.pa.us>
	<4428125D.7000707@tada.se>
	<1143541439.3839.323.camel@localhost.localdomain>
	<44295AB0.5060203@tada.se> <2966.1143563883@sss.pgh.pa.us>
In-Reply-To: <2966.1143563883@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Thomas Hallgren <thomas@tada.se> writes:
>   
>> This FENCED/NOT FENCED terminology would be a good way to
>> differentiate between the two approaches. Any chance of that syntax
>> making it into the PostgreSQL grammar, should the need arise?
>>     
>
> Of what value would it be to have it in the grammar?  The behavior would
> be entirely internal to any particular PL in any case.
>
>   
Not necessarily but perhaps the term FENCED is incorrect for the concept 
that I have in mind.

All languages that are implemented using a VM could benefit from the 
same remote UDF protocol. Java, C#, perhaps even Perl or Ruby. The flag 
that I'd like to have would control 'in-process' versus 'remote'.

I'm not too keen on the term FENCED, since it, in the PL/Java case will 
lead to poorer isolation. Multiple threads running in the same JVM will 
be able to share data and a JVM crash will affect all connected sessions.

Then again, perhaps it's a bad idea to have this in the function 
declaration in the first place. A custom GUC parameter might be a better 
choice. It will not be possible to have some functions use the 
in-process approach and others to execute remotely but I doubt that will 
matter that much.

I'm still eager to hear what it is in the current PL/Java that you 
consider fundamental unresolvable problems.

Regards,
Thomas Hallgren