builtins: support current_timestamp with precision#42633
builtins: support current_timestamp with precision#42633craig[bot] merged 1 commit intocockroachdb:masterfrom
Conversation
|
This change is |
pkg/sql/sem/builtins/builtins.go
Outdated
| Info: txnTSDoc, | ||
| }, | ||
| tree.Overload{ | ||
| Types: tree.ArgTypes{{"precision", types.Int}}, |
There was a problem hiding this comment.
(not sure about needing to support date)
solongordon
left a comment
There was a problem hiding this comment.
now()'s behavior if possible.
Reviewed 6 of 6 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @otan)
docs/generated/sql/functions.md, line 420 at r1 (raw file):
and which stays constant throughout the transaction. This timestamp has no relationship with the commit order of concurrent transactions.</p> </span></td></tr>
Minor: It looks like you accidentally added precision support to now() as well since it shares the same underlying implementation as current_timestamp(). Does this matter? Probably not, but if it's easy enough to avoid then I think we might as well.
docs/generated/sql/functions.md, line 454 at r1 (raw file):
has no relationship with the commit order of concurrent transactions.</p> </span></td></tr> <tr><td><a name="transaction_timestamp"></a><code>transaction_timestamp(precision: <a href="int.html">int</a>) → <a href="timestamp.html">timestamptz</a></code></td><td><span class="funcdesc"><p>Returns the time of the current transaction.</p>
Same story here, though I believe transaction_timestamp is CRDB-specific so seems reasonable to say it follows the same semantics as current_timestamp.
pkg/sql/sem/builtins/builtins.go, line 3553 at r1 (raw file):
Previously, otan (Oliver Tan) wrote…
(not sure about needing to support date)
Shouldn't hurt. Without this we would error out if you tried to insert current_timestamp(x) into a DATE column, which Postgres supports.
otan
left a comment
There was a problem hiding this comment.
Reviewable status:
docs/generated/sql/functions.md, line 454 at r1 (raw file):
Previously, solongordon (Solon) wrote…
Same story here, though I believe
transaction_timestampis CRDB-specific so seems reasonable to say it follows the same semantics ascurrent_timestamp.
Done.
5f072ca to
5ee9712
Compare
|
bors r+ |
solongordon
left a comment
There was a problem hiding this comment.
Reviewable status:
5ee9712 to
625280d
Compare
Canceled |
Release note (sql change): This PR adds new functionality that allows users to use CURRENT_TIMESTAMP with a given precision from 0-6, e.g. `SELECT CURRENT_TIMESTAMP(4)`.
625280d to
d14360d
Compare
|
bors r+ |
Build failed |
|
looks like this got out of space'd bors r+ |
42633: builtins: support current_timestamp with precision r=otan a=otan Resolves #32098 Release note (sql change): This PR adds new functionality that allows users to use CURRENT_TIMESTAMP with a given precision from 0-6, e.g. `SELECT CURRENT_TIMESTAMP(4)`. 42673: roachprod: fix use of GCE_PROJECT r=andreimatei a=andreimatei That env var was supposed to allow one to set the project to use, but it got broken a while ago. Release note: None Co-authored-by: Oliver Tan <otan@cockroachlabs.com> Co-authored-by: Andrei Matei <andrei@cockroachlabs.com>
Build succeeded |
Resolves #32098
Release note (sql change): This PR adds new functionality that allows
users to use CURRENT_TIMESTAMP with a given precision from 0-6, e.g.
SELECT CURRENT_TIMESTAMP(4).