4 ms·
The limitation of PRQL is that it only does SELECTs, by design. If you want to insert/update/delete data, you're back to SQL. That means that your team's data
by Taikonerd 3y ago
The limitation of PRQL is that it only does SELECTs, by design. If you want to insert/update/delete data, you're back to SQL.
That means that your team's data scientist might give you a query written in PRQL, but if you want to actually incorporate it into the data pipeline, you'll need to translate it into SQL.
I wish that PRQL would support at least a limited ability to insert -- for example, maybe just the case of inserting into a new temp table. No update or ON CONFLICT logic to worry about. It could look like this:
from tracks
filter artist == "Bob Marley"
save bob_marley_tmp
- cpursley 3y agoYep, these is where I lost interest.
- 10000truths 3y agoI don't see why PRQL can't support data mutation. Just have an insert/update/delete operator that must go at the end of a pipeline, and which takes a table name as an argument. An SQL query like this: UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%' Could then be written in PRQL as something like this: from counters filter startswith(name, 'prefix.') derive { new_value = value + 1 } select { name, new_value } update counters
- BrentOzar 3y agoThis feels way less intuitive than SQL: UPDATE counters SET value = value + 1 WHERE name LIKE 'prefix.%'
- strken 3y agoI really hate that SQL doesn't let you do UPDATE counters WHERE name LIKE 'prefix.%' SET value = value + 1 In a SELECT it's fine, but in a mutation it's dangerous to make updating literally everything so easy if you leave off the tail.