[
https://issues.apache.org/jira/browse/CALCITE-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16702355#comment-16702355
]
Julian Hyde commented on CALCITE-2713:
--------------------------------------
Sorry, I don't have a PostgreSQL instance.
{{AbstractMethodError}} is usually not your fault, more like a linking problem
(e.g. using a JDBC 3 driver in a JDK that has JDCBC 4.0 or 4.1).
I think you should combine testCastLongVarchar1 and testCastLongVarchar2 into
one test. It makes it easier to see the difference between the handling. After
all, testCastLongVarchar2 is just the null hypothesis.
What do you think of adding {{RelDataTypeSystem SqlDialect.getTypeSystem()}}?
Because {{RelDataTypeSystem}} already has {{int getMaxScale(SqlTypeName
typeName)}}.
> JDBC adapter may generate casts on PostgreSQL for VARCHAR type exceeding max
> length
> -----------------------------------------------------------------------------------
>
> Key: CALCITE-2713
> URL: https://issues.apache.org/jira/browse/CALCITE-2713
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
> Priority: Major
>
> Varchar length in PostgreSQL cannot exceed 10485760, however Calcite may
> generate a cast with length larger than that number, resulting in an
> exception.
> {noformat}
> org.postgresql.util.PSQLException: ERROR: length for type varchar cannot
> exceed 10485760
> {noformat}
> From {{htup_details.h}} in postgresql:
> {noformat}
> * MaxAttrSize is a somewhat arbitrary upper limit on the declared size of
> * data fields of char(n) and similar types. It need not have anything
> * directly to do with the *actual* upper limit of varlena values, which
> * is currently 1Gb (see TOAST structures in postgres.h). I've set it
> * at 10Mb which seems like a reasonable number --- tgl 8/6/00. */
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
