Jan Wieck wrote:
"as you now suggest"? I don't remember suggesting that. I concluded
from your statements that _you_ are against changing Tcl's catch but
instead want the savepoint functionality exposed to plain Tcl. So
_you_ are against _my_ suggestion because these two are mutually
exclusive.
James Robinson <[EMAIL PROTECTED]> writes:
> The JDBC interface exposes the savepoint interface, via setSavepoint(),
> releaseSavepoint(), and rollback(Savepoint sp) methods on the
> Connection, and Thomas's design of PL/Java offers the SPI via mapping
> it onto JDBC. Would client-side JDBC als
On Dec 3, 2004, at 2:04 PM, Jan Wieck wrote:
[snip]
The point we where coming from was Tom's proposal to wrap each and
every single SPI call into its own subtransaction for semantic
reasons. My proposal was an improvement to that with respect to
performance and IMHO also better matching the sema
Jan Wieck <[EMAIL PROTECTED]> writes:
> Your suggestion to expose a plain savepoint interface to the programmer
> leads directly to the possiblity to commit a savepoint made by a
> sub-function in the caller and vice versa - which if I understood Tom
> correctly is what we need to avoid.
If we
On 12/3/2004 12:23 PM, Thomas Hallgren wrote:
Jan Wieck wrote:
There is no "try" in Tcl.
The syntax is
catch { block-of-commands } [variable-name]
Catch returns a numeric result, which is 0 if there was no exception
thrown inside of the block-of-commands. The interpreter result, which
would be th
Jan Wieck wrote:
There is no "try" in Tcl.
The syntax is
catch { block-of-commands } [variable-name]
Catch returns a numeric result, which is 0 if there was no exception
thrown inside of the block-of-commands. The interpreter result, which
would be the exceptions error message in cleartext, is as
On 12/2/2004 3:18 AM, Thomas Hallgren wrote:
Jan,
... plus that the catch-nesting automatically represents the
subtransaction nesting. I can't really see any reason why those two
should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
Jan,
... plus that the catch-nesting automatically represents the
subtransaction nesting. I can't really see any reason why those two
should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
the long run, I still think that savepoints a
On 12/1/2004 1:35 PM, Brett Schwarz wrote:
--- Jan Wieck <[EMAIL PROTECTED]> wrote:
On 12/1/2004 9:23 AM, Jan Wieck wrote:
> On 12/1/2004 4:27 AM, Richard Huxton wrote:
>
>> Thomas Hallgren wrote:
>>> Richard Huxton wrote:
>>>
Can I make some counter-proposals?
1. Wrap each functio
Richard Huxton,
It feels more distinct to me. I'll grant you I'm only a sample size of
1 though.
Perhaps more distinct, but:
- Using savepoints together with try/catch is not exactly an unknown
concept. Try Google and you'll see a fair amount of examples advocating
the approach that I suggest.
-
--- Jan Wieck <[EMAIL PROTECTED]> wrote:
> On 12/1/2004 9:23 AM, Jan Wieck wrote:
>
> > On 12/1/2004 4:27 AM, Richard Huxton wrote:
> >
> >> Thomas Hallgren wrote:
> >>> Richard Huxton wrote:
> >>>
> Can I make some counter-proposals?
>
> 1. Wrap each function body/call (same th
On Wednesday 01 December 2004 04:12, Thomas Hallgren wrote:
> Richard Huxton wrote:
> > Can I make some counter-proposals?
> >
> > 1. Wrap each function body/call (same thing here afaict) in a
> > sub-transaction. An exception can be caught within that function, and
> > all the spi in that function
On 12/1/2004 9:23 AM, Jan Wieck wrote:
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
al
Jan Wieck wrote:
This all would mean that however deeply nested a function call tree,
it would unwind and rollback everything up to the outermost catch. If
there is no catch used, no subtransactions are created and the
unwinding goes all the way up to the statement. If catch is used but
no spi
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then roll
On Wed, 01 Dec 2004 10:29:17 +0100, Thomas Hallgren
<[EMAIL PROTECTED]> wrote:
> Richard Huxton wrote:
>
> > But is the problem not that forgetting to use SAVEPOINT can get us in
> > trouble with clearing up after an exception?
>
> I fail to see how that's different from forgetting to use pgtry i
Thomas Hallgren wrote:
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
of try.
It feels more distinct to me. I'll grant you I'm only a
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
of try.
Regards,
Thomas Hallgren
---(end of broadcast)---
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then rolled back. This is rubbish, but
at least it's
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then rolled back. This is rubbish, but
at least it's predictable and allows
Tom Lane wrote:
Wrapping each individual SPI command in a subtransaction IN NO WAY
prevents us from adding programmer-controllable savepoint features
to the PL languages later.
Ah good - I was coming to the conclusion savepoints/exception handling
were both separately necessary.
> It simply ensu
Tom Lane wrote:
The fundamental point you are missing, IMHO, is that a savepoint is a
mechanism for rolling back *already executed* SPI commands when the
function author wishes that to happen.
Of course. That's why it's imperative that it is the developer that
defines the boundaries. I forsee that
James William Pye <[EMAIL PROTECTED]> writes:
> plpy being an untrusted language, I *ultimately* do not have control
> over this. I can only specify things within my code. I *cannot* stop a
> user from making an extension module that draws interfaces to those
> routines that may rollback to a savep
James William Pye wrote:
I think I may hold a more of a hold nose stance here than Thomas. I am
not sure if I want to implement savepoint/rollback restrictions as I
can't help but feel this is something Postgres should handle; not me or
any other PL or C Function author.
I agree with this but it
While your message was directed at Thomas, I think I share Thomas'
position; well, for the most part.
On Tue, 2004-11-30 at 11:21 -0500, Tom Lane wrote:
> But I think it's a bogus design, because (a) it puts extra burden on the
> function author who's already got enough things to worry about, and
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> From your statement it sounds like you want to use the subtransactions
> solely in a hidden mechanism and completely remove the ability to use
> them from the function developer. Is that a correct interpretation?
No; I would like to develop the abil
Tom Lane wrote:
On what evidence do you base that claim? It's true there are no
existing Tcl or Perl functions that do error recovery from SPI
operations, because it doesn't work in existing releases. That does
not mean the demand is not there. We certainly got beat up on often
enough about the
Tom Lane wrote:
In the case of Perl I suspect it is reasonably possible to determine
whether there is an "eval" surrounding the call or not, although we
might have to get more friendly with Perl's internal data structures
than a purist would like.
Not really very hard. (caller(0))[3] should h
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> I don't understand this either. Why a subtransaction at all?
> Don't get me wrong. I fully understand that a subtransaction would make
> error recovery possible. What I try to say is that the kind of error
> recovery that needs a subtransaction is fa
Richard Huxton <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The real point here is that omitting the per-command subtransaction
>> ought to be a hidden optimization, not something that intrudes to the
>> point of having unclean semantics when we can't do it.
> Sorry to be stupid here, but I di
Richard Huxton wrote:
Tom Lane wrote:
The real point here is that omitting the per-command subtransaction
ought to be a hidden optimization, not something that intrudes to the
point of having unclean semantics when we can't do it.
Sorry to be stupid here, but I didn't understand this when it was
Tom Lane wrote:
The real point here is that omitting the per-command subtransaction
ought to be a hidden optimization, not something that intrudes to the
point of having unclean semantics when we can't do it.
Sorry to be stupid here, but I didn't understand this when it was
disussed originally eit
On 11/29/2004 10:43 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
I don't agree that the right cure is to execute each and every statement
itself as a subtransaction. What we ought to do is to define a wrapper
for the catch Tcl command, that creates a subtransaction and executes
the
Jan Wieck <[EMAIL PROTECTED]> writes:
> I don't agree that the right cure is to execute each and every statement
> itself as a subtransaction. What we ought to do is to define a wrapper
> for the catch Tcl command, that creates a subtransaction and executes
> the code within during that.
What I
On 11/19/2004 7:54 PM, Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
My approach with PL/Java is a bit different. While each SPI call is
using a try/catch they are not using a subtransaction. The catch will
however set a flag that will ensure two things:
1. No more calls can be mad
On Sat, 2004-11-20 at 16:39 -0500, Tom Lane wrote:
> You're right. You can *not* expose those as user-callable operations in
> a PL language. Consider for example what will happen if the user tries
> to roll back to a savepoint that was established outside your function
> call, or tries to exit t
Thomas Hallgren wrote
I'm planning to add subtransactions too, but my approach will be to
use the savepoint functionality already present in the
java.sql.Connection interface. Perhaps the plpy implementation could
do something similar. This is what I'm planning to implement:
In Java, safepoints
Tom Lane wrote:
James William Pye <[EMAIL PROTECTED]> writes:
I have been playing with RollbackToSavepoint and ReleaseSavepoint, but
per Neil's comments on IRC and the fact that I have to annoyingly
construct a List containing the savepoint name. I get the feeling that I
am not meant to use them.
Tom Lane wrote:
There's an ancient saying "I can make this code arbitrarily fast ...
if it doesn't have to give the right answer". I think that applies
here. Fast and unsafe is not how the Postgres project customarily
designs things.
I'm missing something, that's clear. Because I can't see why th
James William Pye <[EMAIL PROTECTED]> writes:
> I have been playing with RollbackToSavepoint and ReleaseSavepoint, but
> per Neil's comments on IRC and the fact that I have to annoyingly
> construct a List containing the savepoint name. I get the feeling that I
> am not meant to use them.
You're r
On Fri, 2004-11-19 at 16:58 -0500, Tom Lane wrote:
> What I think we ought to do is change both PL languages so that every
> SPI call is executed as a subtransaction. If the call elogs, we can
> clean up by aborting the subtransaction, and then we can report the
> error message as a Perl or Tcl er
I wrote:
> I get about 6900 vs 12800 msec, so for a simple pre-planned query
> it's not quite a 50% overhead.
However, that was yesterday ;-). I did some profiling and found some
easy-to-knock-off hotspots. Today I'm measuring about 25% overhead
for a simple SELECT, which I think is entirely acc
Tom Lane <[EMAIL PROTECTED]> writes:
> (I'm sure we can do more to speed up subtransaction entry/exit than we have
> so far.)
Is there anything that can be done to short circuit the _first_ layer of
subtransaction? I'm thinking there will be many cases like this where there's
one implicit subtran
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> That's what pltcl has always done, and IMHO it pretty well sucks :-(
>> it's neither intuitive nor useful.
>>
> Given that most SPI actions that you do doesn't elog (most of them are
> typically read-only), it's far more useful than
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
My approach with PL/Java is a bit different. While each SPI call is
using a try/catch they are not using a subtransaction. The catch will
however set a flag that will ensure two things:
1. No more calls can be made from PL/Jav
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This will slow down the PL SPI call operations in both languages, but
>> AFAICS it's the only way to provide error handling semantics that aren't
>> too broken for words.
> Can you estimate the extent of the slowdown?
Without actuall
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> My approach with PL/Java is a bit different. While each SPI call is
> using a try/catch they are not using a subtransaction. The catch will
> however set a flag that will ensure two things:
> 1. No more calls can be made from PL/Java to the postgres
Tom Lane wrote:
plperl's error handling is not completely broken, but it's close :-(
Consider for example the following sequence on a machine with a
relatively old Perl installation:
You just picked an easy way to trigger this. As you rightly observe,
there are others.
We can deal with this i
Tom Lane wrote:
What I think we ought to do is change both PL languages so that every
SPI call is executed as a subtransaction. If the call elogs, we can
clean up by aborting the subtransaction, and then we can report the
error message as a Perl or Tcl error condition, which the function
author ca
plperl's error handling is not completely broken, but it's close :-(
Consider for example the following sequence on a machine with a
relatively old Perl installation:
regression=# create or replace function foo(int) returns int as $$
regression$# return $_[0] + 1 $$ language plperl;
CREATE FUNCTIO
50 matches
Mail list logo
