On 1/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
> Err, I think you misunderstood what I said. My implementation uses
> SAVEPOINTs already. The point is having some API where you do not have
> to care of you are already in a transaction or not.
It's no
On Jan 2, 2007, at 2:01 PM, Lukas Kahwe Smith wrote:
Tom Lane wrote:
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
Err, I think you misunderstood what I said. My implementation
uses SAVEPOINTs already. The point is having some API where you
do not have to care of you are already in a transac
Tom Lane wrote:
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
Err, I think you misunderstood what I said. My implementation uses
SAVEPOINTs already. The point is having some API where you do not have
to care of you are already in a transaction or not.
It's not that hard, is it?
if (P
On 1/2/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
E.g., no GUC parameter. Just change the behavior or don't.
Please refer the conversation beginning at:
http://archives.postgresql.org/pgsql-hackers/2006-05/msg00249.php
That is where this TODO item came from. In the conversation, it was
u
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
> Err, I think you misunderstood what I said. My implementation uses
> SAVEPOINTs already. The point is having some API where you do not have
> to care of you are already in a transaction or not.
It's not that hard, is it?
if (PQtransactionS
On Tue, 2007-01-02 at 11:53 +0100, Peter Eisentraut wrote:
> Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
> > I think you can make the case that this should be an error, or at least
> > that's how it got on the TODO list. I can always remove it if people
> > don't want the item co
Alvaro Herrera wrote:
news.postgresql.org wrote:
While we are on the topic, I have implemented a poor mans nested
transaction feature into my database access layer. essentially
subsequent calls to begin a transaction after the initial begin simply
increase an internal counter and set a savepo
news.postgresql.org wrote:
> While we are on the topic, I have implemented a poor mans nested
> transaction feature into my database access layer. essentially
> subsequent calls to begin a transaction after the initial begin simply
> increase an internal counter and set a savepoint. as you comm
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
I think you can make the case that this should be an error, or at least
that's how it got on the TODO list. I can always remove it if people
don't want the item completed.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
>> I think you can make the case that this should be an error, or at least
>> that's how it got on the TODO list. I can always remove it if people
>> don't want the item completed.
> The r
Am Donnerstag, 28. Dezember 2006 18:57 schrieb Bruce Momjian:
> I think you can make the case that this should be an error, or at least
> that's how it got on the TODO list. I can always remove it if people
> don't want the item completed.
The reason this was added is that modular applications ex
Am Donnerstag, 28. Dezember 2006 19:52 schrieb Tom Lane:
> Not only is it overzealous, but the proposal to have one reflects a
> failure to learn from history. GUC variables that change
> transaction-boundary semantics are a bad idea, period: see autocommit.
But this option would not, in fact, ch
Robert Treat <[EMAIL PROTECTED]> writes:
> I thought this was needed for spec compliance?
BEGIN isn't in the spec at all ...
Now you could point to the spec for START TRANSACTION, which saith
1) If a statement is executed when an
SQL-transaction is currently active, then an
On Thursday 28 December 2006 15:44, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Thu, 2006-12-28 at 13:52 -0500, Tom Lane wrote:
> > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > > I would say that a GUC variable for such behavior as listed in the
> > > > TODO is overzealous. We sho
Joshua D. Drake wrote:
> On Thu, 2006-12-28 at 13:52 -0500, Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > I would say that a GUC variable for such behavior as listed in the TODO
> > > is overzealous. We should either enforce it, or not. As we do not now,
> > > there is no
On Thu, 2006-12-28 at 13:52 -0500, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > I would say that a GUC variable for such behavior as listed in the TODO
> > is overzealous. We should either enforce it, or not. As we do not now,
> > there is no reason imo to change it.
>
> Not
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> I would say that a GUC variable for such behavior as listed in the TODO
> is overzealous. We should either enforce it, or not. As we do not now,
> there is no reason imo to change it.
Not only is it overzealous, but the proposal to have one reflects
> 1
> (1 row)
>
> test=> COMMIT;
> COMMIT
>
> I think you can make the case that this should be an error, or at least
> that's how it got on the TODO list. I can always remove it if people
> don't want the item completed.
Well I can tell you that my custome
Joshua D. Drake wrote:
> Hello,
>
> Is this really a TODO or is this someone being overzealous with the TODO
> list?
> Add a GUC to control whether BEGIN inside a transcation should abort
> the transaction.
Well, right now, BEGIN inside a transaction just issues a warning:
test=> BEGIN
Hello,
Is this really a TODO or is this someone being overzealous with the TODO
list?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 199
20 matches
Mail list logo
