Support empty string handling for date and time datatypes

[manisha-deshpande]

Add TSQL-compatible handling of empty string ('') for date and time types, defaulting to '1900-01-01' for date and time, similar to datetime, datetime2, datetimeoffset, smalldatetime.

Task: BABEL-3433

Description

In SQL Server, when an empty string ('') is cast to date or time datatype, it should be return a default value - '1900-01-01' for date and '00:00:00.0000000' for time. Currently, Babelfish raises a syntax error for these cases. This change improves TSQL compatibility by matching SQL Server's behavior for empty string handling in date and time datatypes, while maintaining existing behavior for non-empty inputs.

1> create table bug(dt date null, tm time(3) null);
2> insert into bug values ('', '');
go
Msg 33557097, Level 16, State 1, Server BABELFISH, Line 1
invalid input syntax for type date: ""
Msg 33557097, Level 16, State 1, Server BABELFISH, Line 1
invalid input syntax for type time: ""

Changes:

• Modified date_in() and time_in() functions in PostgreSQL engine to check for empty input string before ParseDateTime() and if in TSQL dialect, prepare date and time default values adjusting their time struct and converting to respective return type Datums (by calling date2j and tm2time respectively).
  • This approach mirrors the empty string handling logic in the babelfish_common package for datetime, datetime2, datetimeoffset, and smalldatetime datatypes through the use of initializeToDefaultDatetime().
• Added comprehensive test coverage in the Babelfish JDBC test suite to verify empty string handling across different scenarios including direct casts, table insert operation, type conversions, and formatting functions.

Issues Resolved

BABEL-3433: Support for empty input string handling in date and time datatypes

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the PostgreSQL license, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.

For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[tanscorpio7]

We always put dialect check / hook check as the first thing in the condition.

[RIC06X]

+1

[manisha-deshpande]

Flipped the order. Tests passed locally. It is required to rerun the extensions-side PR tests?

[Anikait143]

This condition would not effectively check for empty string consisting of whitespaces. For eg:

select CAST('    ' as date)

We may consider trimming these spaces first.

[manisha-deshpande]

Good point. Considered this, but left it for now to remain consistent with the other date types (datetime2, datetime, datetimeoffset) that don't check or trim blank strings and return a syntax error:

select CAST('   ' as datetimeoffset)
invalid input syntax for type timestamp with time zone: "   "

It might be good to expand the scope from just date/time datatypes and add the whitespace trimming logic for the other date types as well. Shall I proceed with those changes in this pr itself?

[Anikait143]

Can we check the effort to fix other date/time datatypes as well. I think we should fix all of them if the effort is reasonable.

[Anikait143]

We should also consider fixing this for CASTs from string datatypes to Date/Time.

[manisha-deshpande]

Agreed. Can you help me understand why the sql_dialect check fails for CAST(CAST('' AS VARCHAR) AS DATE/TIME)

• sql_dialect=1 when date_in is invoked implicitly
• sql_dialect=0 when varchar2date invokes date_in

[tanscorpio7]

dialect is changed to PG when executing non-tsql functions. In this case varchar2date.

I think we will need to fix this in two places instead of date_in()

1. tsql_coerce_string_literal_hook for direct constants casted to datetime types.
2. In cast functions while casting from other datatypes

[Anikait143]

Yes, it's Better to have these changes in extension itself as tanzeel mentioned, we can have handlings at two seperate places for string literals and casts respectively.

[manisha-deshpande]

Fix moved to extension side: babelfish-for-postgresql/babelfish_extensions#3807