Subject | Re: [Firebird-Architect] Counter proposal to Temporary tables |
---|---|
Author | Dmitry Yemanov |
Post date | 2004-12-08T14:40:36Z |
"Ann W. Harrison" <aharrison@...> wrote:
easier to implement, I'd consider it logical to see GTTs done first. Then,
we do lots of useful (hopefully) things that are not explicitly sponsored.
Finally, we have devs who are interested in this task. What else do we need
to start working?
future it may become a synonym for LOCAL TEMPORARY TABLE or may be kept as
our non-standard extention if another (standard compliant) LOCAL TT
implementation will be in progress.
Dmitry
>First, since GTTs and LTTs share the same storage strategy and GTTs are
> >First of all, we've already almost agreed on GTTs.
>
> Yes, but we got into this because we had a sponsor for the
> feature. It turns out that the sponsor doesn't want what
> we're agreeing on.
easier to implement, I'd consider it logical to see GTTs done first. Then,
we do lots of useful (hopefully) things that are not explicitly sponsored.
Finally, we have devs who are interested in this task. What else do we need
to start working?
> >As a personal note, I'd stick with <created LTTs> as session-scopeobjects
> >and <declared LTTs> as routine-scope objects to make everyone happy. Thisis
> >one of those very rare cases when I avoid following the standard exactyand
> >treat it the way it's valuable for us and our users.I also proposed a way to solve this issue: SESSION TEMPORARY TABLE. In the
>
> If we choose to implement a non-standard feature, we should
> not bend the language of the standard to fit our feature but
> should implement it with our own language. Always.
future it may become a synonym for LOCAL TEMPORARY TABLE or may be kept as
our non-standard extention if another (standard compliant) LOCAL TT
implementation will be in progress.
Dmitry