Subject | Firebird 2.0 |
---|---|
Author | donjules2k |
Post date | 2004-09-07T11:10:18Z |
Hi,
I was wondering what the development plans and goals were for 2.0. I
would like to make some sugestions on
features which I think would be usefull.
1) Using the IF keyword in standard sql. This would be useful for
writting update scripts which check if a table
or field exists before creating them. Currently I have an update
script which throws errors becuase fields and or
tables already exists.
2) The ability to create and consume temporary tables in a stored
procedures. Running any kind of DDL would be a
bonus.
3) Storing security info in the same file as the DB instead of a
seperate security file.
4) Being able to run a normal select in a stored procedure and have it
return a record set rather than having to
"select into". It is often teadious to have to define paramters and
select values into them. The SQL server
approach would be nice where one can just run some SQL and it returns
one or more recordsets. (I think this might
be a really complex yet usefull feature to acheive)
5) A better SQL parser that would allow the creation of stored
proecures and triggers without using SET TERM.
e.g:
create procedure myExample as
begin
--do stuff
end
If the parser knew to track the "begin" and "end" keywords it
should recognise the SQL block without needing
the set term. This feature would be nice but is by far the least of
priority.
Any thoughts, feedback or other sugestions?
Thanks
Giulio
I was wondering what the development plans and goals were for 2.0. I
would like to make some sugestions on
features which I think would be usefull.
1) Using the IF keyword in standard sql. This would be useful for
writting update scripts which check if a table
or field exists before creating them. Currently I have an update
script which throws errors becuase fields and or
tables already exists.
2) The ability to create and consume temporary tables in a stored
procedures. Running any kind of DDL would be a
bonus.
3) Storing security info in the same file as the DB instead of a
seperate security file.
4) Being able to run a normal select in a stored procedure and have it
return a record set rather than having to
"select into". It is often teadious to have to define paramters and
select values into them. The SQL server
approach would be nice where one can just run some SQL and it returns
one or more recordsets. (I think this might
be a really complex yet usefull feature to acheive)
5) A better SQL parser that would allow the creation of stored
proecures and triggers without using SET TERM.
e.g:
create procedure myExample as
begin
--do stuff
end
If the parser knew to track the "begin" and "end" keywords it
should recognise the SQL block without needing
the set term. This feature would be nice but is by far the least of
priority.
Any thoughts, feedback or other sugestions?
Thanks
Giulio