From: | "Jose' Soares Da Silva" <sferac(at)proxy(dot)bazzanese(dot)com> |
---|---|
To: | ocie(at)paracel(dot)com |
Cc: | "Meskes, Michael" <meskes(at)topsystem(dot)de>, hackers postgres <pgsql-hackers(at)postgreSQL(dot)org>, pgsql-questions-bugs(at)postgreSQL(dot)org, sferac(at)bo(dot)nettuno(dot)it |
Subject: | Re: [HACKERS] drop table inside transactions |
Date: | 1998-04-20 12:00:08 |
Message-ID: | Pine.LNX.3.96.980420114221.882A-100000@proxy.bazzanese.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 17 Apr 1998 ocie(at)paracel(dot)com wrote:
> Meskes, Michael wrote:
> >
> > Is this really a bug? I haven't seen any (commercial) system supporting
> > this kind of transaction recovery. Once you drop a table the data is
> > lost, no matter if you rollback or not.
SOLID restore a dropped table inside a transaction.
> >
> > Michael
>
> I tend to agree. Sybase will not even honor a drop table request
> inside a transaction:
>
> 1> begin tran
> 2> go
> 1> drop table foo
> 2> go
> Msg 2762, Level 16, State 4:
> Line 1:
> The 'DROP TABLE' command is not allowed within a multi-statement transaction in
> the 'ociedb' database.
> 1>
>
> We _could_ do something like check a "deleted" flag in the relation
> and postpone the actual delete until the transaction is committed, but
> at least in my experience, changing table structure is usually best
> left to human admins as opposed to applications. Rows change but the
> basic table structure stays the same until the application and schema
> are changed.
>
What about temporary tables ?
We don't have CREATE TEMPORARY TABLE statement
thus users need to create
and drop tmp tables inside transactions.
Jose'
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SARZ | 1998-04-20 12:06:17 | Re: [HACKERS] drop table inside transactions |
Previous Message | Kapsaris | 1998-04-20 11:37:44 | v6.3.2 build on FreeBSD |