Subject | RE: QLI and ancient IB language |
---|---|
Author | David Schnepper |
Post date | 2000-01-16T07:57:14Z |
-----Original Message-----
From: Claudio Valderrama C. [mailto:cvalde@...]
Sent: Saturday, January 15, 2000 11:09 PM
To: IBDI@onelist.com
Subject: RE: [IBDI] QLI and ancient IB language
From: "Claudio Valderrama C." <cvalde@...>
I agree, Kevin.
Making procedures � la MS was one of my ideas, but I never reserved
time to
write some of the most basic that are needed.
If we want more powerful things to be done, somewhere in the future
IB's
sprocs must have some support to cope with metadata, namely, create
table,
alter view, etc.
--- OK, my ignorance must be showing. For a production database, why
would you need to have a SP available that contains "create table",
etc? While I was in R&D, the viewpoint was that table creation (&
similar metadata activities) were rare once the schema was out of
"development" and the database had gone into production use.
-- I understand, of course, the value of being able to create a table,
alter a domain definition, etc -- but why do you want to put this
activity in a stored procedure?
(Actually, I can think of one possibility -- so that all the
statements run on the server without round trips to the client for
each statement - eg: performance).
- GRANT / REVOKE makes some sense in a SP (particularly if they are
allowed to take a :username parameter).
- One Nit issue also: One reason InterBase didn't allow DDL
statements (such as create table) in a stored procedure is that SQL
(at the time, anyway) didn't allow them. SP were for DML statements.
(Or did I totally misunderstand your remark here? Are you proposing
the creation of SP to handle activities such as "rename table" -- or
the ability to put statements such as "create table" into the body of
a SP?
For the first I think creation of SQL syntax may be a better approach,
and for the 2nd, I honestly don't see where this is useful. (I admit
it's an elegent approach -- allow a SP to have any SQL statement --
with possibily not allowing a SP to contain statements to create a
SP).
(Another aside: Would a UDF such as
eval_DSQL_statement ('create table mytable (...');
handle what you're thinking of here?)
Dave
[This message contained attachments]
From: Claudio Valderrama C. [mailto:cvalde@...]
Sent: Saturday, January 15, 2000 11:09 PM
To: IBDI@onelist.com
Subject: RE: [IBDI] QLI and ancient IB language
From: "Claudio Valderrama C." <cvalde@...>
I agree, Kevin.
Making procedures � la MS was one of my ideas, but I never reserved
time to
write some of the most basic that are needed.
If we want more powerful things to be done, somewhere in the future
IB's
sprocs must have some support to cope with metadata, namely, create
table,
alter view, etc.
--- OK, my ignorance must be showing. For a production database, why
would you need to have a SP available that contains "create table",
etc? While I was in R&D, the viewpoint was that table creation (&
similar metadata activities) were rare once the schema was out of
"development" and the database had gone into production use.
-- I understand, of course, the value of being able to create a table,
alter a domain definition, etc -- but why do you want to put this
activity in a stored procedure?
(Actually, I can think of one possibility -- so that all the
statements run on the server without round trips to the client for
each statement - eg: performance).
- GRANT / REVOKE makes some sense in a SP (particularly if they are
allowed to take a :username parameter).
- One Nit issue also: One reason InterBase didn't allow DDL
statements (such as create table) in a stored procedure is that SQL
(at the time, anyway) didn't allow them. SP were for DML statements.
(Or did I totally misunderstand your remark here? Are you proposing
the creation of SP to handle activities such as "rename table" -- or
the ability to put statements such as "create table" into the body of
a SP?
For the first I think creation of SQL syntax may be a better approach,
and for the 2nd, I honestly don't see where this is useful. (I admit
it's an elegent approach -- allow a SP to have any SQL statement --
with possibily not allowing a SP to contain statements to create a
SP).
(Another aside: Would a UDF such as
eval_DSQL_statement ('create table mytable (...');
handle what you're thinking of here?)
Dave
[This message contained attachments]