[Feature Request] Support native `date.now` function in standard library to reduce S-string usage

[sunyeongchoi]

What's up?

Description

Currently, many temporal functions, including date.now, are not natively supported in PRQL's standard library. To use them, users must resort to S-strings like s"now()" or s"CURRENT_TIMESTAMP".

While S-strings provide a powerful escape hatch, they have several drawbacks:

1. Poor Readability: They break the visual flow of PRQL code.

2. Maintenance: They make the query dialect-dependent, defeating one of PRQL's core strengths (abstraction over SQL dialects).

3. Developer Experience: Writing s"now()" feels less intuitive than a native function call.

Proposed Change

I propose adding a native date.now function to the PRQL standard library. This would allow users to write:

derive [
  created_at = date.now
]

Instead of:

derive [
  created_at = s"now()"
]

Implementation Idea

The date.now function can be added to the stdlib.prql and mapped to the appropriate SQL equivalent based on the target dialect (e.g., NOW() for PostgreSQL/MySQL, CURRENT_TIMESTAMP for others).

I am willing to contribute to this by implementing the date.now function in the standard library if the maintainers agree with this direction.

Additional Context
As PRQL matures, moving frequently used functions from S-strings to the standard library will significantly improve the overall user experience and type-safety potential.

[max-sixty]

yes, very open to adding common functions like this. It would need to be in PRQL form (i.e. not now())!

[sunyeongchoi]

@max-sixty
Does 'PRQL form' mean that I should use now instead of now()? For example, providing it like this:

derive [
  created_at = now
]

instead of using parentheses?

[max-sixty]

yes!

[sunyeongchoi]

Thank you for confirming

[sunyeongchoi]

@max-sixty
One more question. if I want to provide a function like argMax(val1, val2) in PRQL format, should I implement it to work as argMax val1 val2 (using spaces instead of parentheses and commas)?