Changes between Version 1 and Version 2 of Ticket #35793, comment 4


Ignore:
Timestamp:
Oct 23, 2024, 12:56:57 PM (3 weeks ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #35793, comment 4

    v1 v2  
    2121}}}
    2222
    23 Stormheg's report requested that it defaults to the conflicting row (not the `excluded` one) and I think it makes the most sense but I'm unsure if all backends support that. Another argument for this using the conflicting row value over the excluded one is that the latter can be emulated with a `Case(When(...))` if necessary (return distinct value based on unique key match) while the other way around is not possible. It's also easier to implement resolving to the `INSERT` table alias (while disallowing JOINs) as no alias re-pointing needs to take place and if a need eventually arise to support excluded references it would be straightforward to implement a `ExcludedF(F)` class that always resolve to the backend specific equivalent of Postgres's `excluded`.
     23Stormheg's report requested that it defaults to the conflicting row (not the `excluded` one) and I think it makes the most sense but I'm unsure if all backends support that. Another argument for defaulting to the conflicting row value over the excluded one is that the latter can be emulated with a `Case(When(...))` if necessary (return distinct value based on unique key match) while the other way around is not possible.
     24
     25It's also easier to implement resolving to the `INSERT` table alias (while disallowing JOINs) as no alias re-pointing needs to take place and if a need eventually arise to support excluded references it would be straightforward to implement a `ExcludedF(F)` class that always resolve to the backend specific equivalent of Postgres's `excluded`.
Back to Top