Add support for jdbc parameters in ColDataType precision and scale

[tomershay]

Adding support for JDBC parameters (?) in column data types, in precision and scale arguments, such as:

SELECT price::VARCHAR(?) FROM products WHERE quantity = 50;

SELECT price::DECIMAL(?, ?) FROM products WHERE quantity = 50;

SELECT (CAST(? AS VARCHAR(?))) FROM products;

[tomershay]

@manticore-projects could you kindly review this PR please?
Also, do you happen to know why the CI task publishMavenJavaPublicationToOssrhRepository fails with 401?
Thank you so much! :)

[manticore-projects]

I am actually shocked, that Parameters are allowed for this.
Is this really executed on Postgres? And if so, would that not mean that ANY expression was allowed (including sub selects?)

[tomershay]

Thanks for the quick reply.
I might need to revise the title and description of the PR. While this fix uses the JDBC parameters as part of the implementation, the main goal is to support a more general use case where users dynamically assign values in different parts of the query template (using ? placeholders) and later populate them through code.
I think it can be valuable for JSQLParser to be able to use it to parse queries with placeholders practically anywhere in the query.

Looking forward to hearing your thoughts please.

[manticore-projects]

Greetings @tomershay.

In general I agree with you: whenever a Generic Expression is allowed, then a Generic Expression should be parsed (and defined in the Grammar).
Thus I wonder:

1. does Postgres really allow parameters for DataTypes Precision and Scale (I honestly don't know)
2. if so, should we not use SimpleExpression except of just JdbcParameter

Although this will make parsing more expensive of course.

[manticore-projects]

the main goal is to support a more general use case where users dynamically assign values in different parts of the query template (using ? placeholders) and later populate them through code.

Would that not be a query rewrite instead? I don't think this task belongs to the Grammar.
We need to be very careful with performance when using Expression or SimpleExpression.

[tomershay]

does Postgres really allow parameters for DataTypes Precision and Scale (I honestly don't know)

No, I believe JDBC parameters / PG parameterized queries do not support ? in data types / casts.

We need to be very careful with performance when using Expression or SimpleExpression.

Yes I agree, that's the main reason I went with enabling just JDBC Parameters, and not the full syntax or expressions/subqueries, to minimize the scope of impact.

Would that not be a query rewrite instead? I don't think this task belongs to the Grammar.

While this is not strictly part of JDBC/PG grammar, I think supporting placeholders throughout all parts of SQL queries could be valuable for this library, as developers commonly use templated queries. Currently, JSQLParser supports placeholders only in certain cases (like JDBC), which might be confusing. I completely understand though if you think it may not be a good fit. I appreciate the thought and time you've put into it.

[manticore-projects]

does Postgres really allow parameters for DataTypes Precision and Scale (I honestly don't know)

No, I believe JDBC parameters / PG parameterized queries do not support ? in data types / casts.

I thought as much and for me this speaks against merging this change.
As far as I understand it, you are looking for a template engine -- not for a parser.

We need to be very careful with performance when using Expression or SimpleExpression.

Yes I agree, that's the main reason I went with enabling just JDBC Parameters, and not the full syntax or expressions/subqueries, to minimize the scope of impact.

Would that not be a query rewrite instead? I don't think this task belongs to the Grammar.

While this is not strictly part of JDBC/PG grammar, I think supporting placeholders throughout all parts of SQL queries could be valuable for this library, as developers commonly use templated queries. Currently, JSQLParser supports placeholders only in certain cases (like JDBC), which might be confusing. I completely understand though if you think it may not be a good fit. I appreciate the thought and time you've put into it.

Template engine or even a plain Java Message Builder will resolve any variable like $MY_VARIABALE or ${MY_VARIABLE}.

I value and appreciate your work, interest and contribution but I feel we are on the wrong path here.
However, I would like to ask others to share their opinion. This is the perfect case for a public vote.

Please see #2199.

[tomershay]

That's completely fair, I appreciate the time you took to evaluate this PR, and it definitely sounds based on the vote that this implementation probably doesn't belong in the parser. I'll close this PR. Thanks again!

[manticore-projects]

That's completely fair, I appreciate the time you took to evaluate this PR, and it definitely sounds based on the vote that this implementation probably doesn't belong in the parser. I'll close this PR. Thanks again!

Thank you for understanding. We could open a new Repository JSQLTemplate though for all kind of templating stuff araound JSQLParser.