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:
-
Poor Readability: They break the visual flow of PRQL code.
-
Maintenance: They make the query dialect-dependent, defeating one of PRQL's core strengths (abstraction over SQL dialects).
-
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.
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 likes"now()"ors"CURRENT_TIMESTAMP".While S-strings provide a powerful escape hatch, they have several drawbacks:
Poor Readability: They break the visual flow of PRQL code.
Maintenance: They make the query dialect-dependent, defeating one of PRQL's core strengths (abstraction over SQL dialects).
Developer Experience: Writing
s"now()"feels less intuitive than a native function call.Proposed Change
I propose adding a native
date.nowfunction to the PRQL standard library. This would allow users to write:Instead of:
Implementation Idea
The
date.nowfunction 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_TIMESTAMPfor others).I am willing to contribute to this by implementing the
date.nowfunction 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.