At 10:07 PM 11/23/2004, Claudio Valderrama C. wrote:

> >
> > CREATE TEMPORARY TABLE <table name> <table contents source>
> > [ON COMMIT {PRESERVE | DELETE} ROWS]
>
>Even if we are going to discuss a month what's global and local, please make
>the correct syntax from the beginning.

The standard is
CREATE {GLOBAL | LOCAL } TEMPORARY TABLE ...
I left out the {GLOBAL | LCOAL } in my proposal because we
will have ony one kind and that makes the qualification unnecessary.
By all means, let me amend the proposal to

CREATE GLOBAL TEMPORARY TABLE ...

to encourage the touch typing skills of Firebird users.

>ON COMMIT DELETE do you mean? The other way it should be named auto-commit
>delete. :-)

Right...

> > System table support:
> > A new field will be added to RDB$RELATIONS, called
> > RDB$RELATION_TYPE.
>
>Is this done for performance reasons, for keeping the code simple or what?

We need to document that table type in the system tables and I thought
that have a field in RDB$RELATIONS was the way to do it. We could have
values like RDB$RELATION, RDB$ON_COMMIT_DELETE, RDB$VIEW, RDB$EXTERNAL,
RDB$ON_COMMIT_PRESERVE ... whatever.

>I
>remember that rdb$relations has already a flags fields, so it could be used
>if none of the previous arguments apply.

The RDB$FLAGS is too generic. Back when a byte was important,
trying to pack all attributes in a tiny space was dumb, but
excusable.

> Anyway, RDB$RELATION_TYPE is a
>confusing name because it's used to distinguish tables from views.

Actually, it's not. Views are identified by the existence of view_blr,
see comments on the great bit depression above.

> > The syntax AS <query expression>
>
>Someone will have to dig into it.

Has been dug.

>Considering the performance and reliability impact of temporary tables, it
>seems better to suffer the burden of having temporary files at the cost of
>writing more code.

Interesting discussion topic.


Best,


Ann