search

BlazingDB / blazingsql

BlazingSQL is a lightweight, GPU accelerated, SQL engine for Python. Built on RAPIDS cuDF.
https://blazingsql.com
Apache License 2.0
1.92k stars 181 forks source link

[REVIEW] Support for CURRENT_DATE, CURRENT_TIME and CURRENT_TIMESTAMP #1445

Closed Christian8491 closed 3 years ago

Christian8491 commented 3 years ago

This PR closes #1377 . Also in #1377 we can find interesting out discussion about this PR.

GPUtester commented 3 years ago

Please update the changelog in order to start CI tests.

View the gpuCI docs here.

Christian8491 commented 3 years ago

rerun tests

wmalpica commented 3 years ago

One question that I have about this is are we comfortable that the timestamp could be different for different rows depending on when this invoked on each worker

Oh shit!!! I had not thought of that! Damn..... What if we always send a current time variable that comes from the python side via dask to the engine. It could come in handy in the future for other things as well. This time could be added to the context

felipeblazing commented 3 years ago

One question that I have about this is are we comfortable that the timestamp could be different for different rows depending on when this invoked on each worker

Oh shit!!! I had not thought of that! Damn..... What if we always send a current time variable that comes from the python side via dask to the engine. It could come in handy in the future for other things as well. This time could be added to the context

I really dislike the notion of the python side being responsible for doing this as it feels like it should be part of the cpp side but I don't see too many other viable options since we don't want to add a synchronization step to projection kernels. It just feels weird that a runquery will need to take as an input the time it started.