Обсуждение: --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@commandprompt.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@commandprompt.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@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Nikolay Samokhvalov wrote:
> On 3/27/07, Bruce Momjian <bruce@momjian.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@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +