Subject | Re: [Firebird-Architect] transient data sets and procedures |
---|---|
Author | Dmitry Yemanov |
Post date | 2005-02-21T10:15:42Z |
Ann et al,
Regarding temporary datasets vs PSQL.
First, I think that everything DECLAREd within a procedure body should
behave similarly. It means that either local temporary table or transient
data set must be created at the declaration and destroyed upon procedure's
exit. And also be visible only on a per-procedure basis. Exactly like
DECLAREd variables and cursors behave. We don't need different semantics for
the same syntax.
Second, I don't support a proposal to map existing DLTT/transient dataset to
its local declaration. I believe it tends to cause structure mismatches that
will bite everyone at runtime. Eevery structural change will require a lot
of PSQL to be corrected as well. Too complex and risky to be used without
worries.
Third, I think it's too early to talk about passing temporary datasets to
the nested calls, either implicitly via scope inheritance or explicitly via
formal parameters. Personally, I don't like a concept of nested visibility
of local objects (declared at upper levels), be it a special declaration
flag or implemented elsehow. If we want something to be used in the nested
calls, just pass it via the stack (read: using formal parameters). This
works for variables now. We should decide whether it's desirable for cursors
and how it could be done (a tricky question). Then we should think how
temporary datasets fit this semantics.
Since my personal opinion is that PSQL-scoped datasets is a valuable thing
to have, I see two possible solutions:
1) temporary dataset can be created/declared in PSQL, but it's still an
independent session-scope object which is not destroyed upon procedure's
exit. It's visible in nested calls, but this is okay as it's not a local
object, it's just initialized in a procedure.
2) temporary dataset is declared in PSQL and have a procedure-scope
visibility and lifecycle. It can be optionally initialized with a select
expression and/or can be later changed, but its structure must be fixed for
the given procedure. It can be passed to nested calls as an actual parameter
value (realistically thinking, this feature is a separate one). Local
temporary dataset name overrides every session-level table-type object, be
it persistent table, GTT or another session-level temporary dataset.
It's also possible to have both these technics, but it looks too much
complicated at the first glance.
Dmitry
Regarding temporary datasets vs PSQL.
First, I think that everything DECLAREd within a procedure body should
behave similarly. It means that either local temporary table or transient
data set must be created at the declaration and destroyed upon procedure's
exit. And also be visible only on a per-procedure basis. Exactly like
DECLAREd variables and cursors behave. We don't need different semantics for
the same syntax.
Second, I don't support a proposal to map existing DLTT/transient dataset to
its local declaration. I believe it tends to cause structure mismatches that
will bite everyone at runtime. Eevery structural change will require a lot
of PSQL to be corrected as well. Too complex and risky to be used without
worries.
Third, I think it's too early to talk about passing temporary datasets to
the nested calls, either implicitly via scope inheritance or explicitly via
formal parameters. Personally, I don't like a concept of nested visibility
of local objects (declared at upper levels), be it a special declaration
flag or implemented elsehow. If we want something to be used in the nested
calls, just pass it via the stack (read: using formal parameters). This
works for variables now. We should decide whether it's desirable for cursors
and how it could be done (a tricky question). Then we should think how
temporary datasets fit this semantics.
Since my personal opinion is that PSQL-scoped datasets is a valuable thing
to have, I see two possible solutions:
1) temporary dataset can be created/declared in PSQL, but it's still an
independent session-scope object which is not destroyed upon procedure's
exit. It's visible in nested calls, but this is okay as it's not a local
object, it's just initialized in a procedure.
2) temporary dataset is declared in PSQL and have a procedure-scope
visibility and lifecycle. It can be optionally initialized with a select
expression and/or can be later changed, but its structure must be fixed for
the given procedure. It can be passed to nested calls as an actual parameter
value (realistically thinking, this feature is a separate one). Local
temporary dataset name overrides every session-level table-type object, be
it persistent table, GTT or another session-level temporary dataset.
It's also possible to have both these technics, but it looks too much
complicated at the first glance.
Dmitry