From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Nobis Subject: Re: Finally figuring out some ob-sqlite stuff -- for worg? Date: Sun, 10 Nov 2019 10:44:59 +0100 Message-ID: References: <87bltn5it6.fsf@ericabrahamsen.net> <87d0e23lca.fsf@ucl.ac.uk> <87woc956zj.fsf@ericabrahamsen.net> <87r22h53tp.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:51944) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTjmK-0000v9-OZ for emacs-orgmode@gnu.org; Sun, 10 Nov 2019 04:45:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iTjmJ-0003eV-2a for emacs-orgmode@gnu.org; Sun, 10 Nov 2019 04:45:04 -0500 Received: from basilikum.nobis-admin.de ([89.238.71.130]:40214) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iTjmI-0003dE-N2 for emacs-orgmode@gnu.org; Sun, 10 Nov 2019 04:45:03 -0500 Received: from bohne (p200300CD671DE50078FBC566B707384A.dip0.t-ipconnect.de [IPv6:2003:cd:671d:e500:78fb:c566:b707:384a]) by basilikum.nobis-admin.de (Postfix) with ESMTPSA id 3F0E57E0AFA for ; Sun, 10 Nov 2019 10:45:00 +0100 (CET) In-Reply-To: <87r22h53tp.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sat, 09 Nov 2019 09:58:58 -0800") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org Eric Abrahamsen writes: > I was confused in part because the "where exists (select *..." looks > like its main purpose is to return rows. Indeed that's the purpose: Restrict the set of rows upon which update acts on. Here I tried to reformat the statement a bit in order to emphasize its structure: #+begin_src sql UPDATE bookreview SET rating = (select rating from updates where bookreview.id = updates.id) WHERE EXISTS (select * from updates where updates.id = bookreview.id); #+end_src The subselect of the "SET rating" part is a correlated subquery. So if you imagine UPDATE as a kind of loop over the table, the subquery of the SET part is executed once for every row UPDATE acts on (maybe the SQL execution engine optimizes this in some kind, but the mental model here is: run the subquery for every row we visit on our journey throught the table). Only the WHERE EXISTS clause belonging directly to the UPDATE statement will reduce the set of rows to act on. > Will the select subquery actually restrict the values that are > available for updating/comparison in the update statement? No. > Or does the "exists" mean the subquery is treated as a plain yes/no > boolean, and the update still has access to anything it likes? We > could write "where exists (select " to the same effect? Yes. The SELECT clause of an EXISTS subquery (as in the above example) is rather meaningless. So somethimes you see constructs like "where exists (select 1 from ...)". Some SQL engines are not very clever and execute the subquery of such an EXISTS clause unchanged - meaning that way too much data is fetched for the intermediate result (unnecessary IO and maybe polluting caches). Thus the "select 1" as a workaround for those unclever engines. But current engines should have no problems with optimizing these EXISTS subqueries and in that case it does not matter how the select clause looks like - it will be ignored. > In essence, the "where exists" is acting as an "inner join"... Yes, effectively we are simulating an inner join at this point. Sadly, many SQL engines are not able to update rows of join constructs (or at least have quite severe constraints in these cases). Thus we need to build these kinds of workarounds to change data in more complex cases. SQL is quite a capable language, but it has also has some rough edges. :) -- Until the next mail..., Stefan.