Обсуждение: patch for contrib/xml2

Hello,

Here is the patch for contrib/xml2 (attached), that:
 - renames xml_valid() to xml_is_well_formed()
 - adds PG_MODULE_MAGIC; at the beginning of xpath.c
 - introduces xpath_array() function
 - adds some words about that function and caution about libraries to README

I understand that it's too late, but xpath_array() is pretty simple
function (and, actually, this is a tiny step to XQuery sequences).
Besides that, it is mentioned in the current TODO list and I've told
about this before. Actually, this is at least some [minor] addition for
this module for 8.2.

Let me know if I can help somehow else in this direction.

--
Best regards,
Nikolay

"Nikolay Samokhvalov" <samokhvalov@gmail.com> writes:
> Here is the patch for contrib/xml2 (attached), that:
>  - renames xml_valid() to xml_is_well_formed()
>  - adds PG_MODULE_MAGIC; at the beginning of xpath.c
>  - introduces xpath_array() function
>  - adds some words about that function and caution about libraries to README

I've applied the part of this patch that renames xml_valid() to
xml_is_well_formed(), as well as the documentation fix.  The
PG_MODULE_MAGIC problem was already fixed a few days ago.

I did not apply the addition of xpath_array, on the grounds that
it's well past feature freeze and there doesn't seem to be any
consensus in favor of adding it now.  We should revisit this in
8.3 instead.

            regards, tom lane

Should we revisit xpath_array() for 8.3, or is this all in core now?

---------------------------------------------------------------------------

Tom Lane wrote:
> "Nikolay Samokhvalov" <samokhvalov@gmail.com> writes:
> > Here is the patch for contrib/xml2 (attached), that:
> >  - renames xml_valid() to xml_is_well_formed()
> >  - adds PG_MODULE_MAGIC; at the beginning of xpath.c
> >  - introduces xpath_array() function
> >  - adds some words about that function and caution about libraries to README
>
> I've applied the part of this patch that renames xml_valid() to
> xml_is_well_formed(), as well as the documentation fix.  The
> PG_MODULE_MAGIC problem was already fixed a few days ago.
>
> I did not apply the addition of xpath_array, on the grounds that
> it's well past feature freeze and there doesn't seem to be any
> consensus in favor of adding it now.  We should revisit this in
> 8.3 instead.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Should we revisit xpath_array() for 8.3, or is this all in core now?

Not yet, but we are currently discussing how.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Should we revisit xpath_array() for 8.3, or is this all in core now?
>
> Not yet, but we are currently discussing how.

Uh, was this handled?

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > Should we revisit xpath_array() for 8.3, or is this all in core
> > > now?
> >
> > Not yet, but we are currently discussing how.
>
> Uh, was this handled?

Not yet.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Please wait a little bit, I'll send updated patch (xpath_array() in core) tonight or tomorrow.

It seems so that there is no actual needs in other xpath-functions...
Just to recall:
 - xpath_array() produces xml[] as a result -- so, it's possible to process then any of returned XML fragments, with proper type casting;
 - also xpath_boolean(), xpath_string() and xpath_number() were proposed, according current functions from contrib/xml2. They are intended to return scalar value, first found by XPath expression. I saw serious problems with them -- e.g. it's quite ugly to return always first value of the sequence (but it might be useful in practice, surely) and, moreover, from my POV, xpath_string('/a/text()', '<a>very <b>simple</b> example</a>') should produce 'very simple example' (not 'very ' and not 'very  example') -- due to XML semantics. This differs xpath_string() from other two...

So, my proposal is to include only one function and forget about that three until we have a better vision ...

I'll raise other (less important) questions with patch sent, shortly.




--
Best regards,
Nikolay