aleksandar-trajkovic-db commented on code in PR #59671:
URL: https://github.com/apache/spark/pull/59671#discussion_r4415445719
##########
docs/sql-data-sources-jdbc.md:
##########
@@ -382,6 +382,22 @@ logging into the data sources.
</td>
<td>read</td>
</tr>
+ <tr>
+ <td><code>zonelessTimestampAsNTZ</code></td>
+ <td><code>true</code> for Oracle, <code>false</code> for other
dialects</td>
+ <td>
+ When the option is set to <code>true</code>, timestamp types without a
time zone are inferred as Spark's TimestampNTZ type regardless of
<code>preferTimestampNTZ</code>. Otherwise, they follow
<code>preferTimestampNTZ</code>. This option is currently only supported by
Oracle. Its default follows the dialect's legacy TimestampNTZ mapping
configuration: it is <code>false</code> when that configuration is enabled.
Depending on the driver, values read as TimestampNTZ may not keep their
wall-clock time unless <code>timestampNTZAsWallClock</code> is also
<code>true</code>. On writes through a JDBC catalog, it also decides the types
of the target table's columns, and so how the written values are cast. For
tables created with <code>CREATE TABLE ... USING jdbc</code>, the schema is
fixed when the table is created, so set this option in the table's
<code>OPTIONS</code>.
+ </td>
+ <td>read/write</td>
+ </tr>
+ <tr>
+ <td><code>timestampNTZAsWallClock</code></td>
+ <td><code>true</code> for Oracle, <code>false</code> for other
dialects</td>
+ <td>
+ When the option is set to <code>true</code>, TimestampNTZ values are
read and written as <code>java.time.LocalDateTime</code>, preserving the
wall-clock value without a time zone conversion. This requires a JDBC driver
that supports <code>java.time.LocalDateTime</code>. Otherwise, they are
converted through <code>java.sql.Timestamp</code> in the JVM default time zone.
Its default follows the dialect's legacy TimestampNTZ mapping configuration: it
is <code>false</code> when that configuration is enabled (only Oracle has one,
so the default is <code>true</code> for Oracle and <code>false</code> for other
dialects).
Review Comment:
I specifically avoid calling the Oracle legacy conf directly, because the
plan is to do this for all or most connectors in the future. They would use the
same jdbc options and would have a similar conf, so future proofing this doc.
If you still believe it deserve a direct naming of the conf, I will do it.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
