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 1h98ew-00040r-0Y for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Mar 2019 13:32:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h98eu-00063a-Np for pgsql-hackers@arkaria.postgresql.org; Wed, 27 Mar 2019 13:32:00 +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 1h98eu-00063T-7M for pgsql-hackers@lists.postgresql.org; Wed, 27 Mar 2019 13:32:00 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h98eq-00011X-MS for pgsql-hackers@lists.postgresql.org; Wed, 27 Mar 2019 13:31:59 +0000 Received: by mail-qt1-x842.google.com with SMTP id z17so18719006qts.13 for ; Wed, 27 Mar 2019 06:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=xU2nzpEJShvVDbSLhmr6T65COkvdjTG+ovCe5R+Pq9M=; b=gqjt2SUXaFwPlbOhngbKqtxHrwnz8gvF4EUsitLjzcPVg2vM3759WNDB6KMTOkTJT1 ClZnRt++RYAdcDx+VLfg/wurWJNYJIN57WxohuwFpvZQ2VrXSPa40SpsVezZTgnqj5Sc hixQO450pklvkyUSGMYekohm3iuHb5sdzHWw0IF2uOmY3FnN6f+VsHRIqLGyhz/hQyxU y56inivakptdGrGI/CSYzDIl8MYQFGzCAILvbOeO0boHy0PIxRAkfx3/AR7Ykv/SnvI+ 88M4yIgwGVKqw+4gIuKGa1UZum8u0ngqirZxis4Ed8t0W12nD7Re9NlR0XNO3T+qKa4D TaSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=xU2nzpEJShvVDbSLhmr6T65COkvdjTG+ovCe5R+Pq9M=; b=Gv03GbbuUwdtk47i1B4yfJgXyN50cdaU6guDsMC2xGxnoU+RduQhQX0kmNTOZkWSXB sPN1TCStDoyqiV6YGNo5xWEWV7FPibIR8JHVFFggiTfLr06pgOnvL4qsIgxcCZ5pUQHo sK/8FnvkIxg1VQDwTvXwr9kUUOhinTiLk9C7GNIrweAi7HGFf7R9AK8mIaHcs3t5dLd3 6ZTUsvqSa5bX+ON4zL9vn0u02dVmEvkfsCFe56LMrCmG9Tp8oqPtYTVd5SfSKnhCSDme aZQQmnMws5MoaoANnVWQOr8vf20era8kzTtGjEgwy1US8BS8YslYbXxi86rBk2vGzTNs g/Cg== X-Gm-Message-State: APjAAAUpsUTRKDxmgTeHTbhf9AtAqu59zw1ck+3Q6uTLZQSKaQ0rnMzz HWdsi22+ziW7tjkWriiU5YwZAA== X-Google-Smtp-Source: APXvYqwoVBkAVUmrNn6PyvwVpS8LXV4XQWwiPkukpM2i4ea/JJySwDSsuNC8SuVXSr6wrrFIMy2utQ== X-Received: by 2002:a0c:81d4:: with SMTP id 20mr31174764qve.2.1553693515690; Wed, 27 Mar 2019 06:31:55 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id n201sm11675996qka.10.2019.03.27.06.31.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Mar 2019 06:31:55 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id A0332120A86; Wed, 27 Mar 2019 10:31:52 -0300 (-03) Date: Wed, 27 Mar 2019 10:31:52 -0300 From: Alvaro Herrera To: Chapman Flack Cc: Ryan Lambert , pgsql-hackers@lists.postgresql.org, Pavel Stehule , Tom Lane Subject: Re: Fix XML handling with DOCTYPE Message-ID: <20190327133152.GA7791@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5C9B0497.9020802@anastigmatix.net> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Mar-27, Chapman Flack wrote: > On 03/26/19 21:39, Ryan Lambert wrote: > > Should this be clarified as the libxml2 library? That's what I installed > > to build postgres from source (Ubuntu 16/18). If it is the libxml library > > and the "2" is irrelevant > > That's a good catch. I'm not actually sure whether there is any "libxml" > library that isn't libxml2. Maybe there was once and nobody admits to > hanging out with it. Most Google hits on "libxml" seem to be modules > that have libxml in their names and libxml2 as their actual dependency. > > Perl XML:LibXML: "This module is an interface to libxml2" > Haskell libxml: "Binding to libxml2" > libxml-ruby: "The Libxml-Ruby project provides Ruby language bindings > for the GNOME Libxml2 ..." > > --with-libxml is the PostgreSQL configure option to make it use libxml2. > > The very web page http://xmlsoft.org/index.html says "The XML C parser > and toolkit of Gnome: libxml" and is all about libxml2. > > So I think I was unsure what convention to follow, and threw up my hands > and went with libxml. I could just as easily throw them up and go with > libxml2. Which do you think would be better? Daniel Veillard actually had libxml version 1 in that repository (mostly of GNOME provenance, it seems, put together during some W3C meeting in 1998). The version number changed to 2 sometime during year 2000. Version 1 was mostly abandoned at that point, and for some reason everyone keeps using "libxml2" as the name as though it was a different thing from "libxml". I suppose the latter name is just too generic, or because they wanted to differentiate from the old (probably incompatible API) code. https://gitlab.gnome.org/GNOME/libxml2/tree/LIB_XML_1_BRANCH Everyone calls it "libxml2" nowadays. Let's just use that and avoid any possible confusion. If some libxml3 emerges one day, it's quite likely we'll need to revise much more than our docs in order to use it. > On 03/26/19 23:52, Tom Lane wrote: > > Do we need to mention that at all? If you're not building from source, > > it doesn't seem very interesting ... but maybe I'm missing some reason > > why end users would care. > > The three places I've mentioned it were the ones where I thought users > might care: These seem relevant details. > If you agree, I should go through and fix my nodesets to be node-sets. +1 > [1] http://xmlsoft.org/html/libxml-xpath.html#xmlNodeSet : "array of nodes > in no particular order" What this means is "we don't guarantee any specific order". It's like a query without ORDER BY: you may currently always get document order, but if you upgrade the library one day, it's quite possible to get the nodes in another order and you'll not get a refund. So you (the user) should not rely on the order, or at least be mindful that it may change in the future. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services