Ann,

A> REL_permanent_GDML = 2
A> REL_permanent_SQL = 3
A> REL_view_GDML = 4
A> REL_view_SQL = 5
A> REL_external_GDML = 8
A> REL_external_SQL = 9
A> REL_global_temporary_GDML_delete_on_commit = 16
A> REL_global_temporary_SQL_delete_on_commit = 17
A> REL_global_temporary_GDML_preserve_on_commit = 48
A> REL_global_temporary_SQL_preserve_on_commit = 49
A> REL_local_temporary_GDML_delete_on_commit = 80
A> REL_local_temporary_SQL_delete_on_commit = 81
A> REL_local_temporary_GDML_preserve_on_commit = 122
A> REL_local_temporary_SQL_preserve_on_commit = 123

I can't see the difference; it still needs ugly queries.

I don't think it's of paramount importance, but it has to be decided
if this information is intended for user consumption or just internal
engine working. In the former case, providing something that can only
be dealt with with bit algebra, and not providing the necessary
operators in SQL is subtly cruel. Not to mention that stuffing all
that info in a single column violates the most basic normalization
rules, which is ironic for a field whose name starts with RDB. ;-)

Having said that, the vital part is that the info can be queried -
although with weird IN- or CASE-based predicates, and that suffices
me.

Ciao
--
Nando Dessena
http://www.flamerobin.org