Skip to content

fix: Fix Column Type Name for PostgreSQL ARRAY types #2409

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sakthivelmanii wants to merge 1 commit into
base: main
Choose a base branch
from
+35 −1
Open

fix: Fix Column Type Name for PostgreSQL ARRAY types #2409

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion src/main/java/com/google/cloud/spanner/jdbc/JdbcResultSetMetaData.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,9 @@

package com.google.cloud.spanner.jdbc;

import com.google.cloud.spanner.Dialect;
import com.google.cloud.spanner.ResultSet;
import com.google.cloud.spanner.Type;
import com.google.cloud.spanner.connection.ConnectionProperties;
import com.google.common.base.Preconditions;
import java.sql.Connection;
Expand Down Expand Up @@ -192,7 +194,14 @@ public int getColumnType(int column) {

@Override
public String getColumnTypeName(int column) {
return spannerResultSet.getColumnType(column - 1).getCode().name();
Type columnType = spannerResultSet.getColumnType(column - 1);
if (columnType.getCode() == Type.Code.ARRAY && statement instanceof JdbcStatement) {
Dialect dialect = ((JdbcStatement) statement).getConnection().getDialect();
if (dialect == Dialect.POSTGRESQL) {
return "_" + columnType.getArrayElementType().getSpannerTypeName(dialect);
}
}
return columnType.getCode().name();
Copy link
Collaborator

@olavloite olavloite Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we fix this for more than only PostgreSQL arrays? The current implementation will (I think)

  1. Return ARRAY for all GoogleSQL arrays
  2. STRING for PostgreSQL varchar columns (and so forth for each non-array type)

Copy link
Contributor Author

@sakthivelmanii sakthivelmanii Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current implementation will (I think)
Return ARRAY for all GoogleSQL arrays
STRING for PostgreSQL varchar columns (and so forth for each non-array type)

Yes

Should we fix this for more than only PostgreSQL arrays?

Sorry? What do you mean by this?

Copy link
Collaborator

@olavloite olavloite Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I mean is that it is a bit weird that:

  1. GoogleSQL ARRAY<STRING> returns ARRAY, while PostgreSQL ARRAY<STRING> returns _varchar
  2. PostgreSQL STRING returns STRING (instead of varchar), while PostgreSQL ARRAY<STRING> returns _varchar

Copy link
Contributor Author

@sakthivelmanii sakthivelmanii Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. we can change it. I don't think there will be a problem if we change it. So far ARRAY is the only thing which was concerning for me so I changed it.. Right now, there's a complex handling of types in PG. text == varchar == charater varying. We need to maintain one type which will be easy.

If you feel, we should do it, I can incorporate the change.

}

@Override
Expand Down
25 changes: 25 additions & 0 deletions src/test/java/com/google/cloud/spanner/jdbc/JdbcResultSetMetaDataTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@
import static org.mockito.Mockito.when;

import com.google.cloud.ByteArray;
import com.google.cloud.spanner.Dialect;
import com.google.cloud.spanner.ResultSet;
import com.google.cloud.spanner.ResultSets;
import com.google.cloud.spanner.Struct;
Expand Down Expand Up @@ -540,6 +541,30 @@ public void getColumnTypeName() {
}
}

@Test
public void getColumnTypeNameForPostgreSQL() throws SQLException {
Copy link
Collaborator

@olavloite olavloite Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a test that verifies a type name in 'plain text'. That is: I suspect that the current implementation will return something like _varchar[] as the type name for a PostgreSQL array of varchar. That would be incorrect, as the correct name would be either _varchar or varchar[].

Copy link
Contributor Author

@sakthivelmanii sakthivelmanii Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now it will return _varchar. Maybe I will update the test to not to use TEST_COLUMNS but have two examples, only for ARRAY, REGULAR TYPE..

JdbcConnection connection = mock(JdbcConnection.class);
JdbcStatement statement = mock(JdbcStatement.class);
JdbcResultSet resultSet = getFooTestResultSet(statement);
when(connection.getSchema()).thenReturn("");
when(connection.getCatalog()).thenReturn("test-database");
when(statement.getConnection()).then(new Returns(connection));
when(connection.getDialect()).thenReturn(Dialect.POSTGRESQL);

JdbcResultSetMetaData sub = resultSet.getMetaData();

int index = 1;
for (TestColumn col : TEST_COLUMNS) {
if (col.type.getCode() == Type.Code.ARRAY
&& col.type.getSpannerTypeName(Dialect.POSTGRESQL).contains("bool")) {
assertEquals("_boolean", sub.getColumnTypeName(index));
} else if (col.type.getCode() != Type.Code.ARRAY) {
assertEquals(col.type.getCode().name(), sub.getColumnTypeName(index));
}
index++;
}
}

@Test
public void testIsReadOnly() {
for (int i = 0; i < TEST_COLUMNS.size(); i++) {
Expand Down
Loading