julianhyde commented on code in PR #3034:
URL: https://github.com/apache/calcite/pull/3034#discussion_r1081837725
##########
core/src/main/java/org/apache/calcite/sql/SqlDialect.java:
##########
@@ -1002,6 +1004,18 @@ protected static void unparseOffset(SqlWriter writer,
@Nullable SqlNode offset)
}
}
+ /**
Review Comment:
There's a complex mapping between format elements and dialects. But I
suspect that SqlDialect is not the right place to do it, and functions is
closer to the right place.
Hypothetically, someone could be in MySQL dialect and want to enable MySQL's
and Postgres's formatting functions. It's a useful hypothetical. SqlDialect is
used only for a short part of the query life cycle - when going from AST nodes
to SQL text. But functions are around for longer.
I have in mind a map from strings to format elements that is part of the
`SqlLibraryOperators.FORMAT_TIMESTAMP` function, and the same or similar map
that is used by `FORMAT_TIME` and `PARSE_TIMESTAMP` functions. Parse functions
might have an additional parser, because parsing format strings is not always
trivial.
Maybe the aforementioned 'map' and 'parser' would evolve into slightly
larger classes.
When we tackle the different issue for 'how do I translate a MySQL format
string to a BigQuery format string?' - or 'how do I translate a call to
MySQL_FORMAT_TIMESTAMP to a call to BigQuery_FORMAT_TIMESTAMP' - then those
larger classes could be used to drive the proceedings.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@calcite.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
