Re: --enable-xml instead of --with-libxml?

Now we have --with-libxml (and USE_LIBXML constant for #ifdef-s), what
is not absolutely right: XML support is smth that is more general than
"using libxml2 library". E.g., some SQL/XML publishing functions (such
as XMLPI) do not deal with libxml2.

Also, in the future more "non-libxml" functionality could be added to
"XML support" (well, Peter's recent SQL-to-XML mapping functions prove
it).

I think it'd better to rename configure option to --enable-xml and
USE_LIBXML to ENABLE_XML. I'll do it if there are no objections.

--
Best regards,
Nikolay

Nikolay Samokhvalov wrote:
> Now we have --with-libxml (and USE_LIBXML constant for #ifdef-s), what
> is not absolutely right: XML support is smth that is more general than
> "using libxml2 library". E.g., some SQL/XML publishing functions (such
> as XMLPI) do not deal with libxml2.
>
> Also, in the future more "non-libxml" functionality could be added to
> "XML support" (well, Peter's recent SQL-to-XML mapping functions prove
> it).
>
> I think it'd better to rename configure option to --enable-xml and
> USE_LIBXML to ENABLE_XML. I'll do it if there are no objections.

I think it would be better that leaving --with-libxml out (i.e.
compiling without libxml2 support) would only disable those parts in XML
functionality that require libxml2 for their implementation; the rest of
the stuff should be compiled in regardless of the setting.

Is this not what is done currently?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Nikolay Samokhvalov wrote:
> Also, in the future more "non-libxml" functionality could be added to
> "XML support" (well, Peter's recent SQL-to-XML mapping functions
> prove it).

But note that those are not controlled by the --with-libxml switch.

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

On 2/21/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> I think it would be better that leaving --with-libxml out (i.e.
> compiling without libxml2 support) would only disable those parts in XML
> functionality that require libxml2 for their implementation; the rest of
> the stuff should be compiled in regardless of the setting.
>
> Is this not what is done currently?
>

The thing is that some functions of "XML support" are based on
libxml2, some are not. libxml2 contains useful routines to deal with
XML data. Now we have: XMLELEMENT uses such routines and XMLPI
doesn't. Actually, all SQL/XML publishing function could be
implemented w/o libxml2 -- but it's more convenient to use those
routines in some cases... And there is no guarantee that functions
that don't currently use libxml2 will not use them in future.

What I want to propose is just simplification -- consider all XML
stuff as one package, including XML type, SQL/XML publishing, XPath
funcs, additional publishing functions recently added by Peter (btw,
who knows -- maybe libxml2 will help to improve them somehow in
future?), etc.

--
Best regards,
Nikolay

Nikolay Samokhvalov wrote:
> What I want to propose is just simplification -- consider all XML
> stuff as one package, including XML type, SQL/XML publishing, XPath
> funcs, additional publishing functions recently added by Peter (btw,
> who knows -- maybe libxml2 will help to improve them somehow in
> future?), etc.

Well, in terms of predictable interfaces, there is some merit in your
argument.

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

Where are we on this? Peter thought the consistency makes sense, but if
we can provide functionality that doesn't require libxml, why not
do it?

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

Nikolay Samokhvalov wrote:
> On 2/21/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> > I think it would be better that leaving --with-libxml out (i.e.
> > compiling without libxml2 support) would only disable those parts in XML
> > functionality that require libxml2 for their implementation; the rest of
> > the stuff should be compiled in regardless of the setting.
> >
> > Is this not what is done currently?
> >
>
> The thing is that some functions of "XML support" are based on
> libxml2, some are not. libxml2 contains useful routines to deal with
> XML data. Now we have: XMLELEMENT uses such routines and XMLPI
> doesn't. Actually, all SQL/XML publishing function could be
> implemented w/o libxml2 -- but it's more convenient to use those
> routines in some cases... And there is no guarantee that functions
> that don't currently use libxml2 will not use them in future.
>
> What I want to propose is just simplification -- consider all XML
> stuff as one package, including XML type, SQL/XML publishing, XPath
> funcs, additional publishing functions recently added by Peter (btw,
> who knows -- maybe libxml2 will help to improve them somehow in
> future?), etc.
>
> --
> Best regards,
> Nikolay
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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

On 3/27/07, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
>
> Where are we on this? Peter thought the consistency makes sense, but if
> we can provide functionality that doesn't require libxml, why not
> do it?

I'm still for --enable-xml and putting _everything_ XML-related under this
option. My main points are:
- we cannot guarantee that existing libxml2-free functions will not require
them in the future (because libxml2 contains useful routines);
- libxml2-free functions (e.g. Peter's XML mapping functions,
http://momjian.us/main/writings/pgsql/sgml/functions-xml.html#FUNCTIONS-XML-MAPPING)
produce XML values, but we cannot use XPath function for them unless we have
libxml2;
- people will make errors, trying to understand what needs libxml2, and
what doesn't -- approach "all or nothing" is simple and straightforward;

Well, it seems that I have no more arguments :-) If there is no objections,
I'll send the patch tonight.
If I am wrong and it's better to leave libxml2-free capabilities, then IMHO
we need to reflect it explicitly in the docs, what requires libxml2, and
what doesn't

--
Best regards,
Nikolay

Nikolay Samokhvalov wrote:
> On 3/27/07, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> >
> > Where are we on this? Peter thought the consistency makes sense, but if
> > we can provide functionality that doesn't require libxml, why not
> > do it?
>
>
> I'm still for --enable-xml and putting _everything_ XML-related under this
> option. My main points are:
> - we cannot guarantee that existing libxml2-free functions will not require
> them in the future (because libxml2 contains useful routines);
> - libxml2-free functions (e.g. Peter's XML mapping functions,
> http://momjian.us/main/writings/pgsql/sgml/functions-xml.html#FUNCTIONS-XML-MAPPING)
> produce XML values, but we cannot use XPath function for them unless we have
> libxml2;
> - people will make errors, trying to understand what needs libxml2, and
> what doesn't -- approach "all or nothing" is simple and straightforward;
>
>
> Well, it seems that I have no more arguments :-) If there is no objections,
> I'll send the patch tonight.
> If I am wrong and it's better to leave libxml2-free capabilities, then IMHO
> we need to reflect it explicitly in the docs, what requires libxml2, and
> what doesn't

Agreed, let's do the later and update the documentation. Also, do we
output a helpful message if someone tries to use a libxml2 function that
isn't available.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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

On 4/5/07, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> Nikolay Samokhvalov wrote:
> [...]
> > If I am wrong and it's better to leave libxml2-free capabilities, then
> IMHO
> > we need to reflect it explicitly in the docs, what requires libxml2, and
> > what doesn't
>
> Agreed, let's do the later and update the documentation.

So, you are agreed that I am wrong :-) Well... I would be happy hear some
arguments, but I cannot insist on it :-)

Also, do we
> output a helpful message if someone tries to use a libxml2 function that
> isn't available.

Yep, here it is:

INSERT INTO xmltest VALUES (1, '<value>one</value>');
ERROR: no XML support in this installation

I suppose we should change it to "no libxml2 support in this installation",
shouldn't we?

--
Best regards,
Nikolay

I have applied the following patch which adds documentation and an
improved error message for an installation that does not use
--with-libxml.

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

Nikolay Samokhvalov wrote:
> On 4/5/07, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > Nikolay Samokhvalov wrote:
> > [...]
> > > If I am wrong and it's better to leave libxml2-free capabilities, then
> > IMHO
> > > we need to reflect it explicitly in the docs, what requires libxml2, and
> > > what doesn't
> >
> > Agreed, let's do the later and update the documentation.
>
>
> So, you are agreed that I am wrong :-) Well... I would be happy hear some
> arguments, but I cannot insist on it :-)
>
>
> Also, do we
> > output a helpful message if someone tries to use a libxml2 function that
> > isn't available.
>
>
> Yep, here it is:
>
> INSERT INTO xmltest VALUES (1, '<value>one</value>');
> ERROR: no XML support in this installation
>
> I suppose we should change it to "no libxml2 support in this installation",
> shouldn't we?
>
>
>
> --
> Best regards,
> Nikolay

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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

Bruce Momjian wrote:
> I have applied the following patch which adds documentation and an
> improved error message for an installation that does not use
> --with-libxml.
>
>

and you broke the buildfarm ... you need to fix the regression test.

cheers

andrew