sql: support DELETE FROM ... USING #40963
Comments
jordanlewis
added
C-enhancement
|
This seems straightforward to implement, we should consider for 21.1. |
|
Now that #7841 is completed, any plans to support this as well? |
|
Radu, this would make a good intern project. |
|
will this make it into 21.1? we are using fusionauth with cockroach as primary database and the seemingly only remaining problem are such queries |
|
Unfortunately, it won't be in 21.1. Can you explain your usecase? Is it not possible to rewrite the query to use a subquery, eg |
|
We are running FusionAuth in k8 and want to use cockroach together with it. Only Problem seem to be with queries for social logins - https://fusionauth.io/community/forum/topic/950/cockroach-compatibility-problem-on-connector-signin As FusionAuth is closed source I cannot rewrite the query there - and also no clue / if or when they would change it. |
|
I see, thanks. It shouldn't be a lot of work, perhaps we can get it done for a 21.1.x update. |
yuzefovich
added
the
E-quick-win
|
This syntax is also used in apache druid: |
|
@yuzefovich is there a way to help get this into 21.2? |
|
Unfortunately, I think it's unlikely given that there is little time (about 5-6 weeks) left before the code freeze for 21.2 and we have our hands full. |
|
Would love to see it in 21.3 then :) |
|
cc @vy-ton |
|
need this for using with fusionauth |
|
need this for Unleash |
Previously, the statement `DELETE FROM .. USING` would return an unimplemented error. This commit adds production rules in the parser to handle the `USING` clause in a `DELETE` statement, however usage will return an error as support has not been implemented in `optbuilder`. Assists: cockroachdb#40963 Release note (sql change): Parser will now parse statements of the form `DELETE FROM ... USING`.
Previously, the statement `DELETE FROM .. USING` would return an unimplemented error. This commit adds production rules in the parser to handle the `USING` clause in a `DELETE` statement, however usage will return an error as support has not been implemented in `optbuilder`. Assists: cockroachdb#40963 Release note (sql change): Parser will now parse statements of the form `DELETE FROM ... USING`.
|
i am also looking for this solution, i also want to use fusionauth with cockroachdb |
|
We're expecting to support |
101098: kvserver: acquire and switch leases during Raft ticks r=erikgrinaker a=erikgrinaker **kvserver: acquire and switch leases during Raft ticks** This patch eagerly acquires leases, and switches their type when appropriate, during Raft ticks. This avoids incurring lease acquisition latency on the next request to the range. However, it's only effective for unquiesced ranges (which includes all expiration-based ranges), so we retain the corresponding logic in the replicate queue as a fallback, taking effect within 10 minutes or so. Resolves #98433. Epic: none Release note: None **kvserver: eagerly initialize replicas with expiration leases** By default, replicas start out quiesced and only unquiesce in response to range traffic. Since expiration-based leases should not quiesce, and should eagerly acquire leases, this patch eagerly initializes and unquiesces replicas with expiration-based leases when loaded. Touches #98433. Epic: none Release note: None **kvserver: limit concurrent eager lease acquisitions** This patch limits the number of concurrent eager lease acquisitions done by the Raft scheduler to 256 per node (across all stores), configurable via `kv.lease.eager_acquisition_concurrency`. When the limit is reached, further lease acquisition requests are dropped and then retried on the next tick. This only applies to acquisition of expired leases and switching of lease types done by the Raft scheduler, not to lease extensions nor to lease acquisitions driven by client requests. Since expiration leases need to be extended regularly there is little point in throttling them and the cluster must be provisioned to handle them, and client-driven acquisitions are clearly high priority. A more sophisticated policy can be considered later if necessary. Resolves #100426. Epic: none Release note: None 102516: backupccl: support materialized view mutation in restore r=rafiss a=rafiss fixes #101075 Release note (bug fix): Fixed a bug that could prevent RESTORE from working if the backup had a refresh materialized view mutation in it. 103115: docgen: add USING clause to DELETE statement diagram r=yuzefovich a=taroface Add the `USING` clause to the `DELETE` statement diagram. This was implemented in #40963. Epic: none Release note: none Release justification: non-production code change 103143: pg_catalog: use 0 for pg_constraint.conparentid r=rafiss a=rafiss fixes #103135 The Postgres docs say this is: > The corresponding constraint of the parent partitioned table, if this is a constraint on a partition; else zero. Since we don't support partitioning like Postgres, we should always make this zero. This fixes a query that a tool was using to identify foreign key relationships. Release note (bug fix): Stopped using a NULL value for pg_constraint.conparentid. Now the value is hard-coded to 0, since CockroachDB does not support constraints on partitions. 103217: roachtest: fix rust and npgsql blocklists r=rafiss a=rafiss fixes #101724 fixes #102673 backport fixes #102740 backport fixes #101592 Release note: None Co-authored-by: Erik Grinaker <[email protected]> Co-authored-by: Rafi Shamim <[email protected]> Co-authored-by: Ryan Kuo <[email protected]>
Add support for the
USINGclause onDELETE, which allows joining multiple tables for aDELETEclause.This appears similar to #7841, which tracked adding joins to
UPDATE.https://www.postgresql.org/docs/10/sql-delete.html
Epic: CRDB-5498
The text was updated successfully, but these errors were encountered: