#postgresql Czy da radę kwerendę podaną w zalinkowanej odpowiedzi przepisać w sprytny sposób na "upsert"? https://stackoverflow.com/a/30500936 Jedyne co przychodzi do głowy to manualne ustawienie każdego pola po kolei w klauzuli on conflict, co jest bez sensu. Jest przewaga upsert nad podanym w linku kodem?
@RicoElectrico Nie ma chyba rozwiązania, żeby użyć całej krotki "excluded.*". Trzeba specyfikować dokładnie, i o ile rozumiem - to jest niewygodne dla Ciebie, tak?
UPSERT nie wymaga delete. W podanym rozwiązaniu jest delete, a przecież mogą być triggery ON DELETE, więc to nie są równorzędne operacje.
Może jednak specyfikowanie wszystkich pól nie jest "bez sensu"?
@cosmopolitan: Dla mnie specyfikowanie pól bez konkretnej potrzeby kłóci się z DRY, nie za bardzo rozumiem dlaczego nikt nie pomyślał o dodaniu takiej opcji, to aż się prosi.. Że kwerendy nie są do końca równoważne to wiem. ( ͡°͜ʖ͡°)
@RicoElectrico: Ciekawy problem jeśli chodzi o generyczne rozwiązanie dla dowolnej tabeli. Może ten delete jest dobrym podejściem, gdyby wyłączyć triggery, do tego zdaje się potrzebna jest rola 'replica'. Napisz jakie rozwiązanie zastosowałeś.
Czy da radę kwerendę podaną w zalinkowanej odpowiedzi przepisać w sprytny sposób na "upsert"?
https://stackoverflow.com/a/30500936
Jedyne co przychodzi do głowy to manualne ustawienie każdego pola po kolei w klauzuli on conflict, co jest bez sensu.
Jest przewaga upsert nad podanym w linku kodem?
UPSERT nie wymaga delete. W podanym rozwiązaniu jest delete, a przecież mogą być triggery ON DELETE, więc to nie są równorzędne operacje.
Może jednak specyfikowanie wszystkich pól nie jest "bez sensu"?
Że kwerendy nie są do końca równoważne to wiem. ( ͡° ͜ʖ ͡°)
Może ten delete jest dobrym podejściem, gdyby wyłączyć triggery, do tego zdaje się potrzebna jest rola 'replica'. Napisz jakie rozwiązanie zastosowałeś.