You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For all VARCHAR types: Regardless of whether you define a length for the VARCHAR column, the getPrecision() method will always return a hardcoded value of 0.
Within the DuckDBResultSetMetaData.java file, the getPrecision(int column) method in the DuckDB JDBC driver does not return the defined length of a VARCHAR variable. Instead, for VARCHAR types, the getPrecision() method returns a hardcoded value of 0.
This means that even if you define a VARCHAR with a specific length in your DuckDB table, the JDBC driver will not report this length to the client application.
When compared to PostgreSQL implementation, the PostgreSQL JDBC driver provides a more nuanced and informative implementation of getPrecision() compared to the DuckDB driver. Here's how it behaves:
For VARCHAR(n): When you define a column as VARCHAR with a specific length (e.g., VARCHAR(100)), the getPrecision() method will return that defined length (100 in this case).
For VARCHAR (without a length) and TEXT: PostgreSQL treats VARCHAR without a length specifier as equivalent to the TEXT data type, both of which can store strings of virtually unlimited length. In this scenario, the PostgreSQL JDBC driver will typically return a very large value, often Integer.MAX_VALUE (2,147,483,647), to signify that there is no predefined limit.
Though Postgres has more sophisticated handling for precision for different types, like in your example it supports string both with and without length. DuckDB does not support length (as a type modifier) for VARCHAR (modifier is ignored when present), so the JDBC driver returns 0 consistently for all types where precision is not defined, and VARCHAR is one of them.
If you know some piece of software (with a JDBC client) that breaks because of this behaviour - please let us know. We can add special casing for compatibility, but by default we'd rather return 0 consistently.
Hi,
Thanks for responding to this issue.
I used SAS Software with their access to JDBC. When trying to access a table via DuckDB, I can get over all the numeric variables without any issues, but all my Varchar/Char/String variables get a length of 0! basically they end-up as empty fields!!
When I investigated this, it turned out
SAS uses DuckDBResultSetMetaData.java to identify column types and lengths, while other Java Clients, such as DBeaver seems to use DuckDBResultSet.java, according to Google Gemini CLI.
And that's when I went ahead and had Gemini investigate the Postgres JDBC driver for comparison.
Activity
staticlibs commentedon Sep 8, 2025
Hi, thanks for the report!
Though Postgres has more sophisticated handling for precision for different types, like in your example it supports string both with and without length. DuckDB does not support length (as a type modifier) for
VARCHAR(modifier is ignored when present), so the JDBC driver returns0consistently for all types where precision is not defined, andVARCHARis one of them.If you know some piece of software (with a JDBC client) that breaks because of this behaviour - please let us know. We can add special casing for compatibility, but by default we'd rather return
0consistently.ahmedanadwc commentedon Sep 8, 2025
Hi,
Thanks for responding to this issue.
I used SAS Software with their access to JDBC. When trying to access a table via DuckDB, I can get over all the numeric variables without any issues, but all my Varchar/Char/String variables get a length of 0! basically they end-up as empty fields!!
When I investigated this, it turned out
And that's when I went ahead and had Gemini investigate the Postgres JDBC driver for comparison.
Return precision values for non-decimal columns
staticlibs commentedon Sep 9, 2025
@ahmedanadwc
Thanks for the details! I've filed #367 to make the returned values of
getPrecision()call closer to ones returned by Postgres.ahmedanadwc commentedon Sep 9, 2025
That would be great, much appreciated
Return precision values for non-decimal columns
Return precision values for non-dec columns (1.4)
Return precision values for non-dec columns (1.4)