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 sta
Em 08/03/2016 09:33, Dmitry Yemanov escreveu:
> 06.03.2016 16:55, Dimitry Sibiryakov wrote:
> >
>> I think we need DE to make decision.
>
> The only way
>
> CREATE OR ALTER SEQUENCE S;
>
> can be allowed is that is acts as RESTART WITH 0 INCREMENT BY 1 for
> existing sequences.
>
I then see
08.03.2016 17:46, Mark Rotteveel wrote:
> I disagree, the current syntax conforms to the standard.
Unless standard require to throw an error on this syntax, we don't violate
it but
expand for users' convenience.
But as you wish.
--
WBR, SD.
---
On 08/03/16 17:00, Dmitry Yemanov wrote:
> 08.03.2016 19:06, Dimitry Sibiryakov wrote:
>
>> 05.03.2016 22:28, Lester Caine wrote:
>>> It would be nice if we did not have re-order scripts from other
>>> databases so
>>>NOT NULL DEFAULT '30'
>>> has to be
>>>DEFAULT '30' NOT NULL
>>> in Fire
08.03.2016 19:06, Dimitry Sibiryakov wrote:
> 05.03.2016 22:28, Lester Caine wrote:
>> It would be nice if we did not have re-order scripts from other
>> databases so
>>NOT NULL DEFAULT '30'
>> has to be
>>DEFAULT '30' NOT NULL
>> in Firebird.
>
> If DY agree, I can commit this change.
I
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 lo
08.03.2016 17:45, Dmitry Yemanov wrote:
>> But in this case behavior will be inconsistent with plain ALTER TABLE that
>> doesn't
>> >change not mentioned attributes.
> We don't have CREATE OR ALTER for tables, do we?
I just mistyped "ALTER SEQUENCE", sorry.
>> >I hope you won't insist that "A
I disagree, the current syntax conforms to the standard.
Mark
- Bericht beantwoorden -
Van: "Dimitry Sibiryakov"
Aan: "For discussion among Firebird Developers"
Onderwerp: [Firebird-devel] Positioned attributes in CREATE/ALTER sequence
statement
Datum: di
08.03.2016 19:37, Dimitry Sibiryakov wrote:
>
>> The only way
>>
>> CREATE OR ALTER SEQUENCE S;
>>
>> can be allowed is that is acts as RESTART WITH 0 INCREMENT BY 1 for
>> existing sequences.
>>
>> This way the behaviour is consistent: both CREATE and ALTER produce the
>> same result: existence of
08.03.2016 13:33, Dmitry Yemanov wrote:
> The only way
>
> CREATE OR ALTER SEQUENCE S;
>
> can be allowed is that is acts as RESTART WITH 0 INCREMENT BY 1 for
> existing sequences.
>
> This way the behaviour is consistent: both CREATE and ALTER produce the
> same result: existence of generator S wi
06.03.2016 16:55, Dimitry Sibiryakov wrote:
>
> I think we need DE to make decision.
The only way
CREATE OR ALTER SEQUENCE S;
can be allowed is that is acts as RESTART WITH 0 INCREMENT BY 1 for
existing sequences.
This way the behaviour is consistent: both CREATE and ALTER produce the
same r
05.03.2016 22:28, Lester Caine wrote:
> It would be nice if we did not have re-order scripts from other
> databases so
> NOT NULL DEFAULT '30'
> has to be
> DEFAULT '30' NOT NULL
> in Firebird.
If DY agree, I can commit this change.
--
WBR, SD.
Em 07/03/2016 11:32, Dimitry Sibiryakov escreveu:
> 06.03.2016 18:49, Adriano dos Santos Fernandes wrote:
>> If you "create or ALTER" something, you surely need to pass a clause of
>> what you want to alter.
>
>Even if I want to alter nothing?..
>
As I said, then this is not "create or ALTER
06.03.2016 18:49, Adriano dos Santos Fernandes wrote:
> If you "create or ALTER" something, you surely need to pass a clause of
> what you want to alter.
Even if I want to alter nothing?..
In any case, I've added check for alter clauses and now it matches old
behavior. May I
commit?
--
Em 06/03/2016 14:39, Dimitry Sibiryakov escreveu:
> 06.03.2016 18:02, Adriano dos Santos Fernandes wrote:
>> Then you write a proposal and implementation for all commands.
>
>Actually, I cannot remember any other database object that can be created
> with name
> only, except roles. But roles
06.03.2016 18:02, Adriano dos Santos Fernandes wrote:
> Then you write a proposal and implementation for all commands.
Actually, I cannot remember any other database object that can be created
with name
only, except roles. But roles has no "create or alter" command. Which command
did you hav
06.03.2016 18:02, Adriano dos Santos Fernandes wrote:
> For CREATE OR ALTER SEQUENCE alone and hidden in a commit about
> non-positioned clauses, it does not make any sense!!
May be. But before I run to code limitation which will be removed with the
next commit,
I would like to see a comment
Em 06/03/2016 13:09, Dimitry Sibiryakov escreveu:
>
>For me it rather look like he was against unexpected resetting of sequence
> to zero, but
> I don't see in this quote definite objections against ""create if not exists"
> semantics".
> I, personally, think that this semantic is useful
06.03.2016 17:00, Adriano dos Santos Fernandes wrote:
> At the same time, analyzing the standard, I see they allow RESTART [
>>WITH ] in ALTER, i.e., restarting to 0, and we do not allow this
>>syntax.
BTW, currently ALTER SEQUENCE RESTART reset it not to 0, but to initial
value.
--
WBR,
06.03.2016 17:00, Adriano dos Santos Fernandes wrote:
> Not sure if he remembers, but that has already discussed by me and he at
> the time this command was firstly created ;)
>
> ---
>> >I think this command has something weird:
>> >
>> >SQL> create sequence s1 start with 4;
>> >SQL> creat
Em 06/03/2016 10:55, Dimitry Sibiryakov escreveu:
> 06.03.2016 14:47, Adriano dos Santos Fernandes wrote:
>> Because that is not CEATE OR ALTER, that is CREATE OR
>> DO-NOTHING-IF-EXIST and we do not have this command.
>>
>> It's explicitly designed to raise an error.
>
>ALTER is explicitly de
On 6-3-2016 14:47, Adriano dos Santos Fernandes wrote:
> Em 06/03/2016 05:36, Mark Rotteveel escreveu:
>> On 6-3-2016 03:45, Adriano dos Santos Fernandes wrote:
>>> I see two bugs with your implementation. Both of these commands should
>>> raise error:
>>>
>>> create or alter sequence s1;
>>
>> Why
06.03.2016 14:47, Adriano dos Santos Fernandes wrote:
> Because that is not CEATE OR ALTER, that is CREATE OR
> DO-NOTHING-IF-EXIST and we do not have this command.
>
> It's explicitly designed to raise an error.
ALTER is explicitly designed to raise an error. About CREATE OR ALTER I'm
not tha
Em 06/03/2016 06:32, Dimitry Sibiryakov escreveu:
> 06.03.2016 3:45, Adriano dos Santos Fernandes wrote:
>> I see two bugs with your implementation. Both of these commands should
>> raise error:
>>
>> create or alter sequence s1;
>
>This command if perfectly ok from Language Reference POV: bot
Em 06/03/2016 05:36, Mark Rotteveel escreveu:
> On 6-3-2016 03:45, Adriano dos Santos Fernandes wrote:
>> I see two bugs with your implementation. Both of these commands should
>> raise error:
>>
>> create or alter sequence s1;
>
> Why would this one need to raise an error? I think it would be fin
06.03.2016 3:45, Adriano dos Santos Fernandes wrote:
> I see two bugs with your implementation. Both of these commands should
> raise error:
>
> create or alter sequence s1;
This command if perfectly ok from Language Reference POV: both START
WITH/RESTART and
INCREMENT clauses are marked as o
On 06/03/16 08:51, Mark Rotteveel wrote:
>> I don't think that the SQL standard ever imposed an order on these? But
>> > both MySQL and Postgresql seem to standardise on the DEFAULT last :(
> The SQL standard specifies that the default clause follows the data type
> definition. And this is what Fi
On 5-3-2016 22:28, Lester Caine wrote:
> On 05/03/16 13:32, Dimitry Sibiryakov wrote:
>> Currently parser enforce attribute clauses to have a definite positions
>> in the
>> statement. SQL standard doesn't require that.
>> Do you agree that position-insensitive clauses would be more conven
On 6-3-2016 03:45, Adriano dos Santos Fernandes wrote:
> I see two bugs with your implementation. Both of these commands should
> raise error:
>
> create or alter sequence s1;
Why would this one need to raise an error? I think it would be fine that
if it already exists, nothing is done, and if it
Em 05/03/2016 12:38, Dimitry Sibiryakov escreveu:
> 05.03.2016 16:28, Adriano dos Santos Fernandes wrote:
>> Has the conflicts increased with your patch?
>
> No.
>
>> Can I see it? There is different ways to do this.
>
> Attached.
>
I see two bugs with your implementation. Both of these co
On 05/03/16 13:32, Dimitry Sibiryakov wrote:
>Currently parser enforce attribute clauses to have a definite positions in
> the
> statement. SQL standard doesn't require that.
>Do you agree that position-insensitive clauses would be more convenient?
It would be nice if we did not have re-
05.03.2016 16:28, Adriano dos Santos Fernandes wrote:
Has the conflicts increased with your patch?
No.
Can I see it? There is different ways to do this.
Attached.
--
WBR, SD.
Sequence.diff.7z
Description: Binary data
-
Em 05/03/2016 11:08, Dimitry Sibiryakov escreveu:
> 05.03.2016 14:57, Adriano dos Santos Fernandes wrote:
>> Are you talking only about SEQUENCEs?
>
>For now - yes. I have patch for sequences only.
>
My worry is about conflicts when this is done for more commands.
BTW, shouldn't con
05.03.2016 16:32, Dimitry Sibiryakov wrote:
>
> Currently parser enforce attribute clauses to have a definite positions in the
> statement. SQL standard doesn't require that.
> Do you agree that position-insensitive clauses would be more convenient?
Agreed.
> BTW, shouldn't conflicts in dictionar
05.03.2016 14:57, Adriano dos Santos Fernandes wrote:
> Are you talking only about SEQUENCEs?
For now - yes. I have patch for sequences only.
>> >BTW, shouldn't conflicts in dictionary to be fixed?..
>> >
> Hum?
> btyacc: 32 shift/reduce conflicts, 11 reduce/reduce conflicts.
--
WBR
Em 05/03/2016 10:32, Dimitry Sibiryakov escreveu:
>Hello, All.
>
>Currently parser enforce attribute clauses to have a definite positions in
> the
> statement. SQL standard doesn't require that.
>Do you agree that position-insensitive clauses would be more convenient?
>
Are you tal
Hello, All.
Currently parser enforce attribute clauses to have a definite positions in
the
statement. SQL standard doesn't require that.
Do you agree that position-insensitive clauses would be more convenient?
BTW, shouldn't conflicts in dictionary to be fixed?..
--
WBR, SD.
-
37 matches
Mail list logo
