On Friday 08 August 2008 12:49, Vlad Khorsun wrote:

> >> >> So metadata will always works in read-committed mode?
> >> >
> >> > Yes. This is not good
> >>
> >> This is "must be" as for me. Any metadata change must be taken in
> >> account immediately by every existing connection, except of currently
> >> running statements.
> >
> > If statement runs in RepeatableRead transaction, I'm not sure you are
> > right. Why metadata "must be" changed in the middle of such transaction?
>
> Because this transaction is unlucky ;) Well, we may FORCE all
> transactions to take new metadata (at least we have such intent ;) so ...
>
> >> > but looks like quite possible compromise for FB3.
> >> > Implementing complete RepeatableRead with DDL is much more complicated
> >> > task (provided we do not want to have very often conflicts when doing
> >> > DDL).
> >>
> >> I see no value in such mode. Do you offer to long running
> >> transaction to work with already dropped table forever ? :)
> >
> > Yes, certainly. It can read data from the table after DELETE FROM without
> > conditions:) Why should DROP behaviour differ? Only because we can't
> > implement correct behaviour right now :))
>
> ...what the others think ? Is standard contains something in this
> regards ?
>
> // hvlad: I'm afraid we never be able to implement such "correct behaviour"
> :)

From current (FB3) POV I'm completely agreed with you - all DDL should run in
ReadCommitted mode.
What about the future - we may leave an answer for the future :))

Only not forget to document ReadCommitted DDL now.