On 2021/07/28 23:53, Bharath Rupireddy wrote:
> On Wed, Jul 28, 2021 at 11:50 AM Michael Paquier <michael@paquier.xyz> wrote:
>>
>> On Mon, Jul 26, 2021 at 04:57:53PM +0900, Michael Paquier wrote:
>>> FWIW, like Ashutosh upthread, my vote would be to do nothing here in
>>> terms of behavior changes as this is just breaking a behavior for the
>>> sake of breaking it, so there are chances that this is going to piss
>>> some users that relied accidentally on the existing behavior.
>>
>> In short, I would be tempted with something like the attached, that
>> documents RESTART in CREATE SEQUENCE, while describing its behavior
>> according to START. In terms of regression tests, there is already a
>> lot in this area with ALTER SEQUENCE, but I think that having two
>> tests makes sense for CREATE SEQUENCE: one for RESTART without a
>> value and one with, where both explicitely set START.
>>
>> Thoughts?
>
> -1. IMHO, this is something creating more confusion to the user. We
> say that we allow both START and RESTART that RESTART is accepted as a
> consequence of our internal option handling in gram.y. Instead, I
> recommend throwing errorConflictingDefElem or errmsg("START and
> RESTART are mutually exclusive options"). We do throw these errors in
> a lot of other places for various options. Others may have better
> thoughts though.
Per docs, CREATE SEQUENCE conforms to the SQL standard, with some exceptions.
So I'd agree with Michael if CREATE SEQUENCE with RESTART also conforms to
the SQL standard, but I'd agree with Bharath otherwise.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
