[PATCH] Add XMLEXISTS function from the SQL/XML standard
in [PgSql]
|
Prev: recovery getting interrupted is not so unusual as itused to be
Next: [HACKERS] [PATCH] Add _PG_init to PL language handler documentation
From: Robert Haas on 25 May 2010 12:44 On Tue, May 25, 2010 at 12:04 PM, Mike Fowler <mike(a)mlfowler.com> wrote: > Erik Rijkers wrote: >> >> libxml2.x86_64 2.6.26-2.1.2.8 installed >> libxml2-devel.x86_64 2.6.26-2.1.2.8 installed >> > > Thanks for testing my patch Erik. It turns out I've got libxml2 installed at > version 2.7.5. Searching the gnome mailing lists, it turns out > xmlXPathCompiledEvalToBoolean was added (unbelievably) in the very next > version from yours, 2.6.27 (see: > http://mail.gnome.org/archives/xml/2006-October/msg00119.html). We're unlikely to accept this patch if it changes the minimum version of libxml2 required to compile PostgreSQL. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 25 May 2010 13:41 On Tue, May 25, 2010 at 1:09 PM, Mike Fowler <mike(a)mlfowler.com> wrote: >> We're unlikely to accept this patch if it changes the minimum version >> of libxml2 required to compile PostgreSQL > > Why? 2.6.27 is almost 4 years old. Because we work hard to minimize our dependencies and make them as non-onerous as possible. At a minimum, I think it's fair to say that the burden is on you to justify what it's worth bumping the version number. If there is some major speed or performance advantage to using the newer API, maybe we'll consider it. But if it's just a few extra lines of code to work around it, then it's better to write those extra lines of code rather than potentially force users to upgrade packages they're otherwise happy with. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 25 May 2010 14:09 Robert Haas <robertmhaas(a)gmail.com> writes: > On Tue, May 25, 2010 at 1:09 PM, Mike Fowler <mike(a)mlfowler.com> wrote: >>> We're unlikely to accept this patch if it changes the minimum version >>> of libxml2 required to compile PostgreSQL >> >> Why? 2.6.27 is almost 4 years old. > Because we work hard to minimize our dependencies and make them as > non-onerous as possible. > At a minimum, I think it's fair to say that the burden is on you to > justify what it's worth bumping the version number. Yes. Increasing the minimum required version of some library is a Big Deal, we don't do it on a whim. And we definitely don't do it just because it's old. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mike Fowler on 26 May 2010 06:10 Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > >> On Tue, May 25, 2010 at 1:09 PM, Mike Fowler <mike(a)mlfowler.com> wrote: >> >>>> We're unlikely to accept this patch if it changes the minimum version >>>> of libxml2 required to compile PostgreSQL >>>> >>> Why? 2.6.27 is almost 4 years old. >> At a minimum, I think it's fair to say that the burden is on you to >> justify what it's worth bumping the version number. >> > > Yes. Increasing the minimum required version of some library is a Big > Deal, we don't do it on a whim. And we definitely don't do it just > because it's old. > > regards, tom lane > > OK, I consider myself suitably educated/chastised. I now understand why a version bump is such a big deal. Your objections are all reasonable, I suppose I'm just used to living on the bleeding edge of everything. Consequently I have changed the code to produce the same result in a different way without using the new function. I've down-graded my version to 2.6.26 and it all compiles cleanly. Please find attached my revised patch, and thanks all for your advise. Regards, -- Mike Fowler Registered Linux user: 379787
From: Mike Fowler on 26 May 2010 06:47
Peter Eisentraut wrote: > On tis, 2010-05-25 at 15:31 +0100, Mike Fowler wrote: > >> I've been reading the SQL/XML standard and discovered that it defines a >> function named XMLEXISTS that does exactly what the todo item >> xpath_exists defines. My original patch named the function as per the >> todo but I think using the function name from the standard is a better >> idea. So this patch is the same as before, but the function is now named >> XMLEXISTS instead of xpath_exists. >> > > The XMLEXISTS function works with XQuery expressions and doesn't have > the call signature that your patch implements Looking at the manuals of Oracle, Derby and DB2 I see how the call signature differs. I also note that Oracle's implementation is XPath only, Derby's is partial XQuery and DB2 appears to be full XQuery. What do people prefer me to do? I see the options as: 1) Change the call signature to match the standard 2) Change the function name back to xpath_exists Should option one be the more popular there's further choices: 1) Integrate XQuery support to completely match the standard, however this will require the addition of a new library libxquery 2) Leave the XPath as is, inline with Oracle's implementation 3) Hybrid approach. Since XML is a comple time option, add XQuery as another. Conditional completion gives the full XQuery support when available or just the XPath when not Thoughts? -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |