Update SQL reference guide for Log Workspaces #28591
Conversation
Preview links (active after the
|
vishalshah-dd
force-pushed
the
vishalshah/update-sql-reference
branch
from
cdd5aa4 to
51c65d9
Compare
vishalshah-dd
force-pushed
the
vishalshah/update-sql-reference
branch
from
31ae809 to
e7319ff
Compare
| | `month` | `timestamp` | month of the year (`1` - `12`) | | ||
| | `quarter` | `timestamp` | quarter of the year (`1` - `4`) | | ||
| | `year` | `timestamp` | year | | ||
| | `timezone_hour` | `timestamp` | hour of the time-zone offfset | |
There was a problem hiding this comment.
Prob use "timezone" instead of "time-zone" for consistency?
There was a problem hiding this comment.
Actually, I think I'd rather move it to "time zone" as that's how I'm seeing it being used more often in documentations (incl postgres) regardless of the consistency with the literal
| {{< /code-block >}} | ||
|
|
||
| ### `TO_CHAR` | ||
|
|
||
| Supported patterns for date/time formatting: | ||
| | Pattern | Description | |
There was a problem hiding this comment.
We only have this list specified twice, right?
Seems ok to keep it duplicated for now, but might be nice to put into a shared section at least at some point. The more functions that we have that need this, the more useful a shared section would be. I'll defer to you whether that's worth doing now.
There was a problem hiding this comment.
Yep just twice. I had thought about a common section, but decided against it to save the user a click. Agree that it should be moved if it's specified in more often
| to_timestamp(epoch_time) AS formatted_time | ||
| FROM | ||
| event_logs | ||
| to_timestamp('25/12/2025 04:23 pm', 'DD/MM/YYYY HH:MI am') AS ts |
There was a problem hiding this comment.
Something I noticed now that technically is unrelated to this PR: We seem to be inconsistent in how we case function names. E.g., CAST is upper case, this is lower case.
I think it would be good to do this consistently. And I would in general prefer upper case, but that's a weak preference. I think consistency is the more important aspect.
I'm curious on your thoughts here, but regardless I think it would make sense to tackle in a separate PR (so it can be done holistically and make that easier to review).
There was a problem hiding this comment.
Agree, seems like this entire section has them in lower case. I'll make a follow up PR to edit them altogether. Looking at Postgres, I'm seeing them use lower case when listing functions in tables, but upper case in SQL statements. I do prefer that, it's easier on the eyes when scanning through a list but works inside SQL with capitalizing other keywords.
|
/merge |
|
View all feedbacks in Devflow UI.
This merge request is not mergeable yet, because of pending checks/missing approvals. It will be added to the queue as soon as checks pass and/or get approvals.
The expected merge time in
|
dd-devflow
bot
added
mergequeue-status: done
and removed
mergequeue-status: in_progress
labels
What does this PR do? What is the motivation?
In preparation for the GA release for Log Workspaces, we're reviewing public documentation and updating them to match the latest SQL functionality supported by the product.
This PR focusses on:
https://datadoghq.atlassian.net/browse/LOGSQ-830
Merge instructions
Merge readiness:
For Datadog employees:
Merge queue is enabled in this repo. Your branch name MUST follow the
<name>/<description>convention and include the forward slash (/). Without this format, your pull request will not pass in CI, the GitLab pipeline will not run, and you won't get a branch preview. Getting a branch preview makes it easier for us to check any issues with your PR, such as broken links.If your branch doesn't follow this format, rename it or create a new branch and PR.
To have your PR automatically merged after it receives the required reviews, add the following PR comment:
Additional notes