hibernate/hibernate-orm · error · UnsupportedOperationException

GaussDB not support datetime format yet

Error message

GaussDB not support datetime format yet

What it means

GaussDBDialect.appendDatetimeFormat throws UnsupportedOperationException ('GaussDB not support datetime format yet') - the HQL format(datetime as 'pattern') function depends on this hook to rewrite the pattern into database SQL, and the GaussDB dialect has not implemented it, despite inheriting much of PostgreSQLDialect.

Source

Thrown at hibernate-community-dialects/src/main/java/org/hibernate/community/dialect/GaussDBDialect.java:960

	public boolean supportsJdbcConnectionLobCreation(DatabaseMetaData databaseMetaData) {
		return false;
	}

	@Override
	public boolean supportsMaterializedLobAccess() {
		// Prefer using text and bytea over oid (LOB), because oid is very restricted.
		// If someone really wants a type bigger than 1GB, they should ask for it by using @Lob explicitly
		return false;
	}

	@Override
	public boolean supportsTemporalLiteralOffset() {
		return true;
	}

	@Override
	public void appendDatetimeFormat(SqlAppender appender, String format) {
		throw new UnsupportedOperationException( "GaussDB not support datetime format yet" );
	}

	@Override
	public String translateExtractField(TemporalUnit unit) {
		return switch (unit) {
			//WEEK means the ISO week number
			case DAY_OF_MONTH -> "day";
			case DAY_OF_YEAR -> "doy";
			case DAY_OF_WEEK -> "dow";
			default -> super.translateExtractField( unit );
		};
	}

	@Override
	public AggregateSupport getAggregateSupport() {
		return null;
	}

View on GitHub (pinned to fad1729dce)

Solutions

  1. Do the formatting in Java with DateTimeFormatter after fetching the raw timestamp
  2. Replace equality-on-format predicates with range predicates on the raw timestamp (start/end of the formatted period) - also index-friendly
  3. Use a native query with GaussDB's to_char if your GaussDB build provides the PostgreSQL-compatible function
  4. Register a custom function through FunctionContributions implementing the pattern until the dialect ships support

Example fix

// before (HQL, throws on GaussDB)
session.createQuery("from Reading r where format(r.takenAt as 'yyyy-MM-dd') = :day", Reading.class)
    .setParameter("day", "2026-08-21")

// after (range predicate on raw timestamp)
LocalDate day = LocalDate.of(2026, 8, 21);
session.createQuery("from Reading r where r.takenAt >= :s and r.takenAt < :e", Reading.class)
    .setParameter("s", day.atStartOfDay())
    .setParameter("e", day.plusDays(1).atStartOfDay())
Defensive patterns

Strategy: validation

Validate before calling

Dialect d = sessionFactory.getJdbcServices().getDialect();
if (d instanceof GaussDBDialect && hql.contains("format(")) {
    hql = toRangePredicate(hql); // format(t as 'yyyy-MM-dd') = :d -> t >= :start and t < :end
}

Type guard

static boolean supportsDatetimeFormat(Dialect d) {
    return !(d instanceof GaussDBDialect);
}

Try / catch

try {
    rows = session.createQuery(hql).list();
} catch (UnsupportedOperationException e) {
    if (e.getMessage().contains("datetime format")) { /* select raw timestamps, format in Java */ } else throw e;
}

Prevention

When it happens

Trigger: Any HQL containing format() - projections like "select format(t as 'yyyy-MM-dd')", or predicates like "where format(t as 'yyyy-MM') = :ym" - executed while the GaussDB dialect is active. Fails at query translation time, before SQL is issued.

Common situations: Applications migrated from PostgreSQL (where format() works via to_char) to GaussDB and assuming full dialect parity; report queries with date labels; Criteria dynamic filtering by formatted periods.

Related errors


AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/24f1b4b91774b93a. Report an issue: GitHub.