babelfish-for-postgresql / babelfish_extensions / 11042958351

76%

BABEL_5_X_DEV: 77%

push

github

Uninitialized variable fix for ISNUMERIC function with varchar and nvarchar arguments (#2945)

* Fix uninitialised variable issue related to varchar2numeric function

Task: BABEL-5129
Signed-off-by: manisha-deshpande <mmdeshp@amazon.com>

* Test cases for isnumeric function with varchar and nvarchar variables

Task: BABEL-5129
Signed-off-by: “manisha-deshpande” <“dmanisha.work@gmail.com”>

* removing unintended merged commits

Fixing pr comments, added test name to jdbc latest schedule

Task: BABEL-5129
Signed-off-by: “manisha-deshpande” <“dmanisha.work@gmail.com”>

Fixed issue in SP_TABLES() when @table_name parameter has square brackets around underscore (#2940)

Currently, SP_TABLES procedure does not support wild card [], which matches to any character that is specified in
square bracket. Due to this SP_TABLES procedure returns different output when @table_name parameter value is
table_1 and table[_]1. This issue exists because previously we were using helper function sp_tables_internal whose
body language was plpgsql hence we were using PostgresSQL Like operator for comparison, which does not support
square bracket wild card expression. Fixed the issue by removing this helper function and migrating this function logic
inside the SP_TABLES procedure whose language is pltsql and Like operator in pltsql supports square bracket wild card.

Task: BABEL-4128
Signed-off-by: Rohit Bhagat <rohitbgt@amazon.com>

Fix date functions to take into account the timezone setting (#2947)

Issues -

When the timezone parameter group setting is set to something other than the default UTC, Babelfish date
related functions like SYSDATETIME(), SYSDATETIMEOFFSET(), GETDATE() and CURRENT_TIMESTAMP don't take it
into account, while they should. The same issue occurs with a session-level timezone parameter.
SYSDATETIMEOFFSET() function returns datetimeoffset which does not store timezone due to incorrect casting
function.

Changes mad... (continued)

1 of 1 new or added line in 1 file covered. (100.0%)

44950 of 60360 relevant lines covered (74.47%)

162944.62 hits per line