|
1. The only conditions under which a table could be renamed is if no Trigger, Procedure or Computed Column were dependent on it, since they contain table references in the source text.
Accordingly, at that point it would very simple to define a new table and the copy the data. So, it this really required? 2. What other database engines support this feature? How is it implemented? 3. Unless the SQL Standard supports such a feature, and in the absence of a compelling list of other databases engine which support same, I do not believe that Firebird should implement such a non-conformant feature 1. Well partly agree, Yes you would require to rename it regardless, but coping data is an extra task IMHO that can take a lot more time then renaming a table even today.
2. Let's start from the database list: A. PostgreSQL - http://www.postgresql.org/docs/8.3/static/sql-altertable.html B. MySQL - http://dev.mysql.com/doc/refman/5.0/en/alter-table.html C. SQLite - http://www.sqlite.org/lang_altertable.html D. HSQLDB - http://hsqldb.org/doc/guide/ch09.html 3. There is no SQL standard for it as far as I know, but it sure help a lot. 4. Why does the Firebird developers are so against it ? If there is an answer about it, I sure it will also help a lot more to understand this. Even to add it to firebirdsql can solve a lot of head acks regarding the issue. Anyway, thank you for your answers. Ido,
Thanks for your detailed reply, very appreciated. Please do not take my comments about the case as being any suggestion that "the Firebird developers are so against it". They are simply my personal comments/observations. Until such time as this case is closed with an equivalent "won't fix" status, the comments are simply that, comments. I find it interesting, that while the documentation references does describe the command syntax: - the PostgreSQL, MySQL and HSSQL documentation doesn't make reference to the *impact* of the rename on existing triggers/procedures. - the SQLite documentation suggests that existing triggers/procedures are silently "orphaned" -- not the most desiable way to handle such an operation. While I can understand why a "rename" syntax might be a good thing, the impact of such an operation on the related/dependent structures/SQL is much too complex to be done in any of the ways described above. Sean,
1) If stored proc/trigger/check/computed-by invalidation would be implemented, it would only be just a matter of invalidating those, just like Oracle does. A wider perspective over a particular problem doesn't hurt sometimes. 2) It doesn't affect the validity of the request in the bit. 3) I struggled but ultimately failed to detect even the slightest trace of logic in that statement, unless, of course, alienating users is your primary goal in this project -- then you might be on to something. Cosmin"
"1) If stored proc/trigger/check/computed-by invalidation would be implemented, it would only be just a matter of invalidating those, just like Oracle does. A wider perspective over a particular problem doesn't hurt sometimes. " - The original post makes no mention of metadata "invalidation", which Firebird doesn't currently support. It simply describes "2) It doesn't affect the validity of the request in the bit." - I didn't say that it did, I was looking for some details of other engines which supported it. - whether other databases implement the feature and how their design compares to Firebird does matter, in so far as understanding how they might have; implemented the feature, constrained its application and whether the engine is a simple DBMS with a SQL front-end or a true engine. "3) I struggled but ultimately failed to detect even the slightest trace of logic in that statement, unless, of course, alienating users is your primary goal in this project -- then you might be on to something. " If that was my goal, I would simply follow your example. Did you read my 2nd reply to Ido? I meant that a SQL standard syntax would help a lot in terms of worrying about implementation and possible future changes. The fact there is no SQL standard simply means that the implementation is the feature would be "non-compliant", which means that the syntax needs to be carefully considered -- the Project has spent a lot of time working on bringing the engine into compliance and into adopting compliant feature. This isn't a "home project" that invents things on a "whim", we need to have a broader review/consideration. Since it's too late for water, how'bout more gas: your message got out of my lexer like this:
You do not believe that firebird should implement such a non-conformant feature, unless 1) someone presents you with a compelling list (??) of other database engines which supports the feature (??), and/or 2) the standard specifies it. Now, I strongly believe that: 1) this is your standard answer to most requests on the tracker and it usually comes with the agility I learned to respect. 2) a non-standard feature doesn't make a database any less standards-compliant -- it's the standard features that have to deal with that. 3) the usefulness of a feature has nothing to do with whether it is present or not in other engines or standards on this universe. 4) you have good intentions. Please do not fight over this.
I do wish to better understand why such feature should not be implemented. The cons that I can think of are: A. You break your old code, and it's not an easy task to refactor a database. B. It's not a standard complaint -> hence if tomorrow there will be SQL 2020 (for example) it will break such feature. C. Design a database is a very strict task and should be made only after careful understanding of numerous things variant from the needs. The pros that I can think of are: A. It's easier then creating a new table and copy data (you still need to change the name of the table in everything that uses it) B. More compliance with most used DBMS that exists today (Oracle, MySQL, PostgreSQL, SQLight ...) C. It can start a new set of tools for better administrating the database. D. You can still do this task today, but it will only make it easier to achieve the same task. If there are other pros and cons it is a good idea to add them. I really do not know if adding such feature is a good practice to a database, however at the end it makes things easier to handle, at least in the way it feels. Cosmin:
"...your message got out of my lexer like this:" You need to update your lexer. "Now, I strongly believe that: 1) this is your standard answer to most requests on the tracker and it usually comes with the agility I learned to respect. 2) a non-standard feature doesn't make a database any less standards-compliant -- it's the standard features that have to deal with that. 3) the usefulness of a feature has nothing to do with whether it is present or not in other engines or standards on this universe." 1 - most cases/feature requests are "off the top of my head, this seems to be a good thing" type of submissions, which are rooted in concepts fostered by file based databases with simple SQL front-ends, and lack a sense of what referential integrity is about and it's implications for databases. I ask for "justification" because the requests need to be thought through... and the "requester" needs to be part of that process. 2 - I never said that a non-standard feature makes the database non-compliant -- again, update your lexer. 3 - True, but the usefullness of a feature has everything to do with context. The fact that another engine which dooesn't have triggers/stored procedures have implemented the feature would mean absolutely nothing, since the engine has none of the feature which makes Firebird, Firebird. "4) you have good intentions." As do you. Ido,
"I do wish to better understand why such feature should not be implemented." I have not said that it shouldn't be implemented, just that there are issues to be carefully considered. This feature could only be implemented after support for "invalidating" metadata objects was added to the Firebird engine, since attempting to replace all table references in the source 'code' of the dependent objects would be much too risky to consider. (This is how Oracle and Postgres have implemented the feature -- they mark all existing objects as invalid and require the developer to correct the references themselves.) If that wasn't what you said, I'm ready to eat a Futurama movie popcorn action figurine. I'll even update my lexer, compiler, and other parts of my brain at your choosing :) ... but before I do, I find your 1 point to be an arrogant underestimation of your users... but again, an update of my lexer may (or may not) invalidate the above statement. we'll see after the operation.
Cosmin,
"I find your 1 point to be an arrogant underestimation of your users" I have read and reviewed (edited many as well) *each and every entry* that has been logged to the project trackers, so my comment is not so much arogant but rather based on experience. Further, I think it entirely appropriate to "play devil's advocate" and challenge feature requests. isql has nothing to do with this crazy request.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Trivial
Ability to rename a table
I think you also need invalidation of stored procs and triggers in order to have this (there's a request for that too), otherwise the implementation of RENAME would have to change the stored sql code, which is somehting I know firebird doesn't do by principle.