Re: Default scale and precision SQL data types

[Timo Walther]

Hi Sergei,

please check with the SQL standard before. Most of these values have 
been derived from the standard. I don't like the default of TIMESTAMP(6) 
for timestamps but this is what the standard dictates. Same for not 
allowing VARCHAR(0) or VARCHAR defaulting to VARCHAR(1).


Changes to the type system affect a lot of downstream projects and 
people. Be aware that the FLIP might not be accepted.


Regards,
Timo


On 07.03.24 10:05, lorenzo.affe...@ververica.com.INVALID wrote:

Hello Sergei!

The proposal makes a lot of sense, and Martijn is right as well.
Are you willing to drive the FLIP effort?
Do you need any assistance with that?
On Mar 4, 2024 at 01:48 +0100, Martijn Visser , wrote:

Hi,

I think it would first require a FLIP, given it touches on the core type
system of SQL.

Best regards,

Martijn

On Sat, Mar 2, 2024 at 5:34 PM Sergei Morozov  wrote:


Hi there,

org.apache.flink.table.api.DataTypes allows the creation of temporal data
types by specifying precision (e.g. TIME(3)) or omitting it (TIME()). The
ability to omit precision for temporal types was introduced in
apache/flink@36fef44
<
https://github.com/apache/flink/commit/36fef4457a7f1de47989c8a2485581bcf8633b32



.

Unfortunately, this isn't possible for other data types (e.g. CHAR,
DECIMAL).
Even though they define defaults for length, precision, and scale, their
values have to be passed to the method explicitly.

Would a PR be accepted which will introduce the methods for the remaining
types similar to the temporal ones?

Thanks.

Re: Default scale and precision SQL data types

[lorenzo . affetti]

Hello Sergei!

The proposal makes a lot of sense, and Martijn is right as well.
Are you willing to drive the FLIP effort?
Do you need any assistance with that?
On Mar 4, 2024 at 01:48 +0100, Martijn Visser , wrote:
> Hi,
>
> I think it would first require a FLIP, given it touches on the core type
> system of SQL.
>
> Best regards,
>
> Martijn
>
> On Sat, Mar 2, 2024 at 5:34 PM Sergei Morozov  wrote:
>
> > Hi there,
> >
> > org.apache.flink.table.api.DataTypes allows the creation of temporal data
> > types by specifying precision (e.g. TIME(3)) or omitting it (TIME()). The
> > ability to omit precision for temporal types was introduced in
> > apache/flink@36fef44
> > <
> > https://github.com/apache/flink/commit/36fef4457a7f1de47989c8a2485581bcf8633b32
> > > >
> > .
> >
> > Unfortunately, this isn't possible for other data types (e.g. CHAR,
> > DECIMAL).
> > Even though they define defaults for length, precision, and scale, their
> > values have to be passed to the method explicitly.
> >
> > Would a PR be accepted which will introduce the methods for the remaining
> > types similar to the temporal ones?
> >
> > Thanks.
> >

Re: Default scale and precision SQL data types

[Martijn Visser]

Hi,

I think it would first require a FLIP, given it touches on the core type
system of SQL.

Best regards,

Martijn

On Sat, Mar 2, 2024 at 5:34 PM Sergei Morozov  wrote:

> Hi there,
>
> org.apache.flink.table.api.DataTypes allows the creation of temporal data
> types by specifying precision (e.g. TIME(3)) or omitting it (TIME()). The
> ability to omit precision for temporal types was introduced in
> apache/flink@36fef44
> <
> https://github.com/apache/flink/commit/36fef4457a7f1de47989c8a2485581bcf8633b32
> >
> .
>
> Unfortunately, this isn't possible for other data types (e.g. CHAR,
> DECIMAL).
> Even though they define defaults for length, precision, and scale, their
> values have to be passed to the method explicitly.
>
> Would a PR be accepted which will introduce the methods for the remaining
> types similar to the temporal ones?
>
> Thanks.
>

Default scale and precision SQL data types

[Sergei Morozov]

Hi there,

org.apache.flink.table.api.DataTypes allows the creation of temporal data
types by specifying precision (e.g. TIME(3)) or omitting it (TIME()). The
ability to omit precision for temporal types was introduced in
apache/flink@36fef44

.

Unfortunately, this isn't possible for other data types (e.g. CHAR, DECIMAL).
Even though they define defaults for length, precision, and scale, their
values have to be passed to the method explicitly.

Would a PR be accepted which will introduce the methods for the remaining
types similar to the temporal ones?

Thanks.