Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5Xzw-0006vX-AH for pgsql-hackers@arkaria.postgresql.org; Sun, 17 Mar 2019 15:46:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h5Xzu-0007uw-Nc for pgsql-hackers@arkaria.postgresql.org; Sun, 17 Mar 2019 15:46:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5Xzu-0007up-Ci for pgsql-hackers@lists.postgresql.org; Sun, 17 Mar 2019 15:46:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h5XzM-00020V-MU for pgsql-hackers@postgresql.org; Sun, 17 Mar 2019 15:46:49 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x2HFjYcM005147; Sun, 17 Mar 2019 11:45:34 -0400 From: Tom Lane To: Chapman Flack cc: Ryan Lambert , pgsql-hackers@postgresql.org Subject: Re: Fix XML handling with DOCTYPE In-reply-to: <5C8D79AF.7010204@anastigmatix.net> References: <5C8D5D16.7090206@anastigmatix.net> <23319.1552769738@sss.pgh.pa.us> <5C8D6681.4070504@anastigmatix.net> <24203.1552771272@sss.pgh.pa.us> <5C8D79AF.7010204@anastigmatix.net> Comments: In-reply-to Chapman Flack message dated "Sat, 16 Mar 2019 18:33:19 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5145.1552837534.1@sss.pgh.pa.us> Date: Sun, 17 Mar 2019 11:45:34 -0400 Message-ID: <5146.1552837534@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Chapman Flack writes: > On 03/16/19 17:21, Tom Lane wrote: >> Hm, so, maybe just >> >> (1) always try to parse as document. If successful, we're done. >> >> (2) otherwise, if allowed by xmloption, try to parse using our >> current logic for the CONTENT case. > What I don't like about that is that (a) the input could be > arbitrarily long and complex to parse (not that you can't imagine > a database populated with lots of short little XML snippets, but > at the same time, a query could quite plausibly deal in yooge ones), > and (b), step (1) could fail at the last byte of the input, followed > by total reparsing as (2). That doesn't seem particularly likely to me: based on what's been said here, I'd expect parsing with the wrong expectation to usually fail near the start of the input. In any case, the other patch also requires repeat parsing, no? It's just doing that in a different set of cases. The reason I'm pressing you for a simpler patch is that dump/reload failures are pretty bad, so ideally we'd find a fix that we're comfortable with back-patching into the released branches. Personally I would never dare to back-patch the proposed patch: it's too complex, so it's not real clear that it doesn't have unwanted side-effects, and it's not at all certain that there aren't libxml version dependencies in it. (Maybe another committer with more familiarity with libxml would evaluate the risks differently, but I doubt it.) But I think that something close to what I sketched above would pass muster as safe-to-backpatch. regards, tom lane