From: Robert Haas on 6 May 2010 11:43 On Thu, May 6, 2010 at 10:10 AM, Mike Fowler <mike(a)mlfowler.com> wrote: > Hi hackers, > > Although this is a very small change I figured I'd practice the policy of > outlining your change before you write the code and attempt a patch > submission. Essentially I see the function as a convenience function that > exposes the results of the xpath built in exists() function as a boolean for > easier SQL. The syntax will match the xpath function already present: > > xpath_exists(xpath, xml[, nsarray]) > > The implementation will check that the xpath value contains 'exists(.....)' > and add it if not present for added usability. I can't blindly wrap the > value with exists(...) as exists(exists(.....)) will always return true in > xpath. I've not allocated the oid yet, but will try to earn my bonus points > for getting it close to xpath()'s oid. :) Appropriate regression tests will > be added after I've ensured that 'make check' is happy I've not regressed > anything. I'm not sure I understand how this more convenient than just using xpath() with exists()? > Can I confirm that contrib/xml2 is deprecated and I should be carrying out > my work in backend/utils/adt/xml.c? Yes. -- 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: mike on 6 May 2010 17:53 Quoting Robert Haas <robertmhaas(a)gmail.com>: > > I'm not sure I understand how this more convenient than just using > xpath() with exists()? > It will save a lot of complexity in WHERE clauses. For example using exists() in xpath() you might construct something like: WHERE array_dims(xpath('exists(/foo/bar)','<bar><foo/></bar>'::xml) IS NOT NULL ... Whereas a dedicated xpath_exists() would look like: WHERE xpath_exists('/foo/bar','<bar><foo/></bar>'::xml) .... I accept this example is quite basic, but I hope it illustrates the added usability. I think xml in sql is complex enough, especially when you start considering namespaces, that anything we can do to simplify common use cases can only help improve the uptake of postgres xml. Thanks, -- Mike Fowler -- 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 6 May 2010 22:40 On Thu, May 6, 2010 at 5:53 PM, <mike(a)mlfowler.com> wrote: > Quoting Robert Haas <robertmhaas(a)gmail.com>: > >> >> I'm not sure I understand how this more convenient than just using >> xpath() with exists()? >> > > It will save a lot of complexity in WHERE clauses. For example using > exists() in xpath() you might construct something like: > > WHERE array_dims(xpath('exists(/foo/bar)','<bar><foo/></bar>'::xml) IS NOT > NULL ... > > Whereas a dedicated xpath_exists() would look like: > > WHERE xpath_exists('/foo/bar','<bar><foo/></bar>'::xml) .... > > I accept this example is quite basic, but I hope it illustrates the added > usability. I think xml in sql is complex enough, especially when you start > considering namespaces, that anything we can do to simplify common use cases > can only help improve the uptake of postgres xml. Oh, I see. Well, that might be reasonable syntactic sugar, although I think you should make it wrap the path in exists() unconditionally, rather than testing for an existing wrap. Please email your patch to the list (replying to this email is fine) and add it here: https://commitfest.postgresql.org/action/commitfest_view/open -- 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: Mike Fowler on 7 May 2010 05:46 Robert Haas wrote: > Oh, I see. Well, that might be reasonable syntactic sugar, although I > think you should make it wrap the path in exists() unconditionally, > rather than testing for an existing wrap. > I'll leave it out for now, it saves me some effort after all. > Please email your patch to the list (replying to this email is fine) > and add it here: > https://commitfest.postgresql.org/action/commitfest_view/open > Will do once I've finished. Thanks for your feedback. Regards, -- 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
From: Mike Fowler on 11 May 2010 05:21 Robert Haas wrote: > Please email your patch to the list (replying to this email is fine) > and add it here: > https://commitfest.postgresql.org/action/commitfest_view/open > Here's my patch, developed against HEAD, that adds the function 'xpath_exists'. The function is a lot simpler than originally thought, so none of the string manipulation previously discussed was required. I've also included some regression tests that test the function with and without xml namespaces. I should note that before I added my tests all existing tests passed. One observation that can be made is that I've largely copied the existing xpath function and altered it to use a different method from the libxml API. I've done it to save me redoing all the namespace handling, however it's apparent to me that if we wanted to expose more of the libxml api we will quickly start having a lot of duplicate code. I notice that refactoring existing code whilst adding new code is generally frowned upon, so once this patch is accepted I will look to refactor the xpath and xpath_exists function. I could even add an xpath_count method at the same time ;) . Thanks in advance for any and all feedback, -- Mike Fowler Registered Linux user: 379787 "I could be a genius if I just put my mind to it, and I, I could do anything, if only I could get 'round to it" -PULP 'Glory Days'
|
Next
|
Last
Pages: 1 2 Prev: [HACKERS] Adding xpath_exists function Next: SQLSTATE for Hot Standby cancellation |