3 ms·
I 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
by 10000truths 3y ago
I 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.