On 03/08/2016 07:56 PM, Dmitry Yemanov wrote: > 08.03.2016 19:50, Dimitry Sibiryakov wrote: > >> But you are still sure that "CREATE OR ALTER" must alter attributes that are >> not >> explicitly mentioned in query?.. > I believe that both CREATE and ALTER parts should deliver the same > object state. I agree that changing non-referenced attributes looks > weird and may confuse users. I don't insist this is absolutely correct. > But the only alternative is to reject such syntax, as we do now. I don't > see any other options, sorry.
Dmitry, I do not agree that CREATE and ALTER parts should deliver the same object state. This depends upon did object exist before performing that operator or not. Take a look at such sample: CREATE OR ALTER USER usr1 PASSWORD 'pass1'; Should this statement reset to NULLs first, middle and last names if user "usr1" already exists when we execute that statement? Using mentioned logic the answer is YES, current behaviour is NO. I've always treated CREATE OR ALTER as create when not exists using mentioned attributes, alter when exists using mentioned attributes. What you describe (reset to default) is sooner behaviour of RECREATE, not CREATE OR ALTER. Operator, creating sequence when it not exists but keeping it as was when exists, makes good sense for various update DB structure scripts. Resetting value to default will lead to duplicated values in various places where unique one are needed. Recreating operator is also useful - but why mix them? ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
