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 <[email protected]> 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 >> <[email protected]> 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
