> Adriano dos Santos Fernandes wrote:
>> Vlad Khorsun wrote:
>>
>>> c) Syntax rule 3 means truncated table must not participate in FOREIGN KEY constraints as
>>> master table.
>>> ORACLE relaxed this rule and allow self-referenced constraints. I think we can follow it.
>>>
>>>
>> Can't we also allow it when all detail tables are being truncated on the
>> same transaction?
>>
>>
>>
>
> There are serious problems making TRUNCATE transactional. For example,
> what happens when a transaction does TRUNCATE then an insert into the
> table, then rolls back. It can be handled -- anything can with enough
> effort, resource, and time -- but is it feasible? Database systems
> built around logs can be made to handle this, but Firebird doesn't have
> a log.
>
> Savepoints make things even worse. Imagine having to undo a TRUNCATE in
> nested savepoints.
>
> How do you recommend that Firebird handle the following:
>
> insert
> truncate

Remember in undo-log list of pointer pages and index root page,
delete entries in rdb$pages, make zero index root's in IRT

> insert
> truncate

Get existing undo-log record and free all the pages recorded there

Remember in undo-log list of pointer pages and index root page,
delete entries in rdb$pages, make zero index root's in IRT

> insert
> truncate

Get existing undo-log record and free all the pages recorded there

Remember in undo-log list of pointer pages and index root page,
delete entries in rdb$pages, make zero index root's in IRT

> rollback

Free all table pages

Get existing undo-log record and insert into rdb$pages all PP's. Also
restore indices root's in IRT


I think its too complex and not sure it is enough therefore i not recommended
to go this way

> The SQL committee not-with-standing, almost every serious designer
> having contemplated the runtime and permission problems has decided that
> TRUNCATE is a DDL, not DML, operation.

Agree. Note, we already agreed to implement TRUNCATE as DDL.

Regards,
Vlad