From: Robert Haas on
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
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
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
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
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'