Re: CALCITE-5678/CALCITE-5957: Datetime literal validation

[stanilovsky evgeny <es...@gridgain.com>]

Thank you, Stamatis.

I vote for direct following the SQL standard, i.e.:
only strict SQL standard compliant literals

date like 10-1-1 is strange and contain huge field for human errors.

> Hey everyone,
>
> CALCITE-5678, which landed recently in Avatica, enforces strict
> validation of datetime literals and is inline with the SQL standard
> specification. However, this strict validation also leads to behavior
> changes (e.g., CALCITE-5957) since some previously "valid" dates are
> now considered invalid.
>
> Roughly four people have expressed an opinion on the aforementioned
> JIRAs but since this is a change that will likely have wider impact I
> would prefer to gather some more inputs from the community.
>
> I created a very brief anonymous survey [1] with a few sample literals
> to aid the decision on what Calcite/Avatica should consider valid and
> invalid from now onwards.
>
> I will close the survey in 96 hours from now. Please fill in the
> survey and/or comment under the respective tickets.
>
> Based on the feedback we can opt to do one of the following:
> * Revert CALCITE-5678 (restore the liberal parsing of datetime literals)
> * Merge CALCITE-5957 (stricter parsing but leading zeros are optional)
> * Reject CALCITE-5957 (only strict SQL standard compliant literals)
>
> Best,
> Stamatis
>
> [1] https://forms.gle/23f3yVhJCKZJdqQu8

Re: CALCITE-5678/CALCITE-5957: Datetime literal validation

[Julian Hyde <jh...@gmail.com>]

We seem to have reached consensus, and I accept that. 

But I can’t let Evgeny’s statements about the SQL standard go unchallenged. When the standard says things like “a date literal in a statement shall be in ISO format”[1] it is saying that, to comply with the standard, a DBMS only needs to make those cases work where literals are in ISO format. The standard does not express any opinion about whether a DBMS should support literals that are not in ISO format. A DBMS such as Postgres that goes beyond the standard is considered to comply with the standard based solely on whether it correctly handles the cases prescribed by the standard. 

Julian

[1] It doesn’t contain that text literally. But it does contain thousands of assertions in that form. 

> On Oct 3, 2023, at 5:38 AM, Stamatis Zampetakis <za...@gmail.com> wrote:
> 
> Indeed the ideal would be to have some liberty around the supported
> datetime formats and it would be great if we find people who want to
> contribute in this direction.
> 
> However, this discussion is more about converging and taking a
> decision around CALCITE-5678 and CALCITE-5957.
> 
> The results of the survey are not really conclusive since the
> participation was rather low (4 responses). So far everybody agrees
> that the SQL standard literal is valid but there are different
> opinions about the rest.
> 
> Given the input so far, I am leaning towards leaving the repo as it is
> for now. This means that CALCITE-5678 remains in place and it is a
> breaking change that will come in the next Avatica version and do
> nothing for CALCITE-5957.
> 
> We can revisit this decision in the future if necessary. Thanks
> everyone for your inputs!
> 
> Best,
> Stamatis
> 
>> On Sun, Oct 1, 2023 at 9:56 AM stanilovsky evgeny
>> <es...@gridgain.com> wrote:
>> 
>> Thank you, Stamatis.
>> 
>> I vote for direct following the SQL standard, i.e.:
>> only strict SQL standard compliant literals
>> 
>> date like 10-1-1 is strange and contain huge field for human errors.
>> 
>>> Hey everyone,
>>> 
>>> CALCITE-5678, which landed recently in Avatica, enforces strict
>>> validation of datetime literals and is inline with the SQL standard
>>> specification. However, this strict validation also leads to behavior
>>> changes (e.g., CALCITE-5957) since some previously "valid" dates are
>>> now considered invalid.
>>> 
>>> Roughly four people have expressed an opinion on the aforementioned
>>> JIRAs but since this is a change that will likely have wider impact I
>>> would prefer to gather some more inputs from the community.
>>> 
>>> I created a very brief anonymous survey [1] with a few sample literals
>>> to aid the decision on what Calcite/Avatica should consider valid and
>>> invalid from now onwards.
>>> 
>>> I will close the survey in 96 hours from now. Please fill in the
>>> survey and/or comment under the respective tickets.
>>> 
>>> Based on the feedback we can opt to do one of the following:
>>> * Revert CALCITE-5678 (restore the liberal parsing of datetime literals)
>>> * Merge CALCITE-5957 (stricter parsing but leading zeros are optional)
>>> * Reject CALCITE-5957 (only strict SQL standard compliant literals)
>>> 
>>> Best,
>>> Stamatis
>>> 
>>> [1] https://forms.gle/23f3yVhJCKZJdqQu8

Re: CALCITE-5678/CALCITE-5957: Datetime literal validation

[Stamatis Zampetakis <za...@gmail.com>]

Indeed the ideal would be to have some liberty around the supported
datetime formats and it would be great if we find people who want to
contribute in this direction.

However, this discussion is more about converging and taking a
decision around CALCITE-5678 and CALCITE-5957.

The results of the survey are not really conclusive since the
participation was rather low (4 responses). So far everybody agrees
that the SQL standard literal is valid but there are different
opinions about the rest.

Given the input so far, I am leaning towards leaving the repo as it is
for now. This means that CALCITE-5678 remains in place and it is a
breaking change that will come in the next Avatica version and do
nothing for CALCITE-5957.

We can revisit this decision in the future if necessary. Thanks
everyone for your inputs!

Best,
Stamatis

On Sun, Oct 1, 2023 at 9:56 AM stanilovsky evgeny
<es...@gridgain.com> wrote:
>
> Thank you, Stamatis.
>
> I vote for direct following the SQL standard, i.e.:
> only strict SQL standard compliant literals
>
> date like 10-1-1 is strange and contain huge field for human errors.
>
> > Hey everyone,
> >
> > CALCITE-5678, which landed recently in Avatica, enforces strict
> > validation of datetime literals and is inline with the SQL standard
> > specification. However, this strict validation also leads to behavior
> > changes (e.g., CALCITE-5957) since some previously "valid" dates are
> > now considered invalid.
> >
> > Roughly four people have expressed an opinion on the aforementioned
> > JIRAs but since this is a change that will likely have wider impact I
> > would prefer to gather some more inputs from the community.
> >
> > I created a very brief anonymous survey [1] with a few sample literals
> > to aid the decision on what Calcite/Avatica should consider valid and
> > invalid from now onwards.
> >
> > I will close the survey in 96 hours from now. Please fill in the
> > survey and/or comment under the respective tickets.
> >
> > Based on the feedback we can opt to do one of the following:
> > * Revert CALCITE-5678 (restore the liberal parsing of datetime literals)
> > * Merge CALCITE-5957 (stricter parsing but leading zeros are optional)
> > * Reject CALCITE-5957 (only strict SQL standard compliant literals)
> >
> > Best,
> > Stamatis
> >
> > [1] https://forms.gle/23f3yVhJCKZJdqQu8