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
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
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
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
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
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
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.
--
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>
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
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;
>>
>>
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
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:
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
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
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
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
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
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
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
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
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
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.
--
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
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.
32 matches
Mail list logo
