[Bug]: Inconsistent handling of type modifier in time columns defintion

[staticlibs]

What happened?

Babelfish accepts type modifier 7 for time, datetime2 and datetimeoffset columns. Internally it is handled as 6 that is a max precision for these types in Postgres.

There is a discrepancy with handling typemod 7 in DDL when the typename is bare or when it is enclosed in square brackets.

Without brackets:

create table tab1(
    col1 time(7)
)

select a.attname, a.atttypmod 
from pg_catalog.pg_attribute a
join pg_catalog.pg_class c on c.oid = a.attrelid  
where c.relname = 'tab1'
and a.attname = 'col1'

attname    atttypmod
---------- -----------
col1       -1

With brackets:

create table tab2(
    col2 [time](7)
)

select a.attname, a.atttypmod 
from pg_catalog.pg_attribute a
join pg_catalog.pg_class c on c.oid = a.attrelid  
where c.relname = 'tab2'
and a.attname = 'col2'

attname    atttypmod
---------- -----------
col2       6

It seems that the discrepancy happens on the parsing stage, the former (bare) variant does not have any typmod expressions at this point. So it does not reach the typemodin call for the time data type that returns 6 given 7 as input.

This discrepancy does not affect data handling (precision 6 is used in both cases), but it can affect tooling that use DB introspection, for example the bcp in #3120 .

Version

BABEL_4_X_DEV (Default)

Extension

babelfishpg_tsql (Default)

Which flavor of Linux are you using when you see the bug?

Fedora

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct.