Le jeudi 3 septembre 2009 à 21:09:56, Dave Page a écrit :
> 2009/9/3 Guillaume Lelarge :
> > Done. Here is the new patch. The check menu item behaves the same way
> > than the others, ie it completely controls the option value. I think it
> > is more consistent this way.
>
> Yeah, that looks how I'
On Thu, Sep 3, 2009 at 21:09, Dave Page wrote:
> 2009/9/3 Guillaume Lelarge :
>
>> Done. Here is the new patch. The check menu item behaves the same way than
>> the
>> others, ie it completely controls the option value. I think it is more
>> consistent this way.
>
> Yeah, that looks how I'd expect
2009/9/3 Guillaume Lelarge :
> Done. Here is the new patch. The check menu item behaves the same way than the
> others, ie it completely controls the option value. I think it is more
> consistent this way.
Yeah, that looks how I'd expect.
I think we should add a TODO to copy all the options that
Le jeudi 3 septembre 2009 à 14:08:54, Guillaume Lelarge a écrit :
> Le jeudi 3 septembre 2009 à 14:02:24, Dave Page a écrit :
> > On Thu, Sep 3, 2009 at 12:57 PM, Magnus Hagander
wrote:
> > > Good question. In general we shouldn't change the default behavior in
> > > a backpatch, but I think the u
Le jeudi 3 septembre 2009 à 14:02:24, Dave Page a écrit :
> On Thu, Sep 3, 2009 at 12:57 PM, Magnus Hagander wrote:
> > Good question. In general we shouldn't change the default behavior in
> > a backpatch, but I think the use-case for the current behavior is
> > pretty limited.
>
> It's not being
2009/9/3 Dave Page :
> On Thu, Sep 3, 2009 at 12:57 PM, Magnus Hagander wrote:
>
>> Good question. In general we shouldn't change the default behavior in
>> a backpatch, but I think the use-case for the current behavior is
>> pretty limited.
>
> It's not being back-patched. That code has been there
On Thu, Sep 3, 2009 at 12:57 PM, Magnus Hagander wrote:
> Good question. In general we shouldn't change the default behavior in
> a backpatch, but I think the use-case for the current behavior is
> pretty limited.
It's not being back-patched. That code has been there for years, with
only one comp
On Wed, Sep 2, 2009 at 10:50, Guillaume Lelarge wrote:
> Le mardi 1 septembre 2009 à 12:44:08, Dave Page a écrit :
>> 2009/8/31 Guillaume Lelarge :
>> > Here is a patch to add this feature. It adds a new setting ("Disable Auto
>> > ROOLBACK") in the Query tag of the Options Dialog. This is of cours
Le mardi 1 septembre 2009 à 12:44:08, Dave Page a écrit :
> 2009/8/31 Guillaume Lelarge :
> > Here is a patch to add this feature. It adds a new setting ("Disable Auto
> > ROOLBACK") in the Query tag of the Options Dialog. This is of course for
> > 1.11.
> >
> > Comments?
>
> ROLLBACK I hope :-)
>
2009/8/31 Guillaume Lelarge :
> Here is a patch to add this feature. It adds a new setting ("Disable Auto
> ROOLBACK") in the Query tag of the Options Dialog. This is of course for 1.11.
>
> Comments?
ROLLBACK I hope :-)
Looks good - my only comment is whether the option should be to
disable or
Le vendredi 21 août 2009 à 09:51:32, Guillaume Lelarge a écrit :
> Le vendredi 21 août 2009 à 09:14:22, Dave Page a écrit :
> > On Thu, Aug 20, 2009 at 10:09 PM, Guillaume
> >
> > Lelarge wrote:
> > > // If the transaction aborted for some reason, issue a rollback to
> > > cleanup. if (conn->GetTxS
Le vendredi 21 août 2009 à 09:14:22, Dave Page a écrit :
> On Thu, Aug 20, 2009 at 10:09 PM, Guillaume
>
> Lelarge wrote:
> > // If the transaction aborted for some reason, issue a rollback to
> > cleanup. if (conn->GetTxStatus() == PGCONN_TXSTATUS_INERROR)
> >conn->ExecuteVoid(wxT("ROLLBACK;")
On Thu, Aug 20, 2009 at 10:09 PM, Guillaume
Lelarge wrote:
> // If the transaction aborted for some reason, issue a rollback to cleanup.
> if (conn->GetTxStatus() == PGCONN_TXSTATUS_INERROR)
> conn->ExecuteVoid(wxT("ROLLBACK;"));
>
> We should perhaps have an option to enable/disable this behavi
Le jeudi 20 août 2009 à 16:16:07, DUPREZ Cédric a écrit :
> [...]
> This problem seems to come from the fact that PgAdmin executes code in a
> single transaction statement...
>
I'm sure it doesn't. Try to do the following steps:
BEGIN;
CREATE temp TABLE toto (id int);
INSERT INTO toto VALUES (1);
Hi,
I am using PgAdmin 1.10.0 with Postgresql 8.3.7 on Windows XP Pro (SP3).
The problem I am facing deals with savepoint and rollback management in PgAdmin.
I initiate a transaction, then I run different queries, create a savepoint :
begin;
CREATE temp TABLE toto (id int);
INSERT IN
15 matches
Mail list logo
