Dear Josh and Andrew,
Thanks for the prompt replies. For now it's just a paper. It was Rob and
Pim's mission to find out if the SQL /XML standard can be implemented
using the postgresql extension mechanism. Building it into the parser was
no option.
Best, Djoerd.
On Thu, 18 Aug 2005, Andrew Dunstan wrote:
>
> IIRC, Peter Eisentraut noted a while ago that implementing the SQL/XML
> functions properly would require building them into the postgresql
> parser as special cases. That of course would mean we wouldn't be using
> the extension mechanism, and is something we should normally shy away
> from, but I think it could be contemplated for something that is in the
> standard.
>
> The paper does not seem to have addressed the issue of how this could be
> done other than bu using the extension mechanism - that seems a bit of a
> pity, although maybe that's exactly the topic they were set.
>
> cheers
>
> andrew
>
> Josh Berkus wrote:
>
> >Paul, Rob,
> >
> >I just read with some interest your paper on XML queries with PostgreSQL.
> >I'm particularly puzzled by some of your conclusions, and thought you might
> >want to discuss them with the PGSQL-Hackers mailing list.
> >
> >Particulary:
> >Functions should be able to have a variable amount of arguments.
> >
> >I find this conclusion odd, because function overloading (that is, the idea
> >that a function is defined by the combination of its name and the number and
> >type of arguments) is now enshrined in the SQL2003 standard. Of course,
> >I wouldn't be at all surprised to find out that the SQL committee had broken
> >their own standard. ;-)
> >
> >Re-defining AS would, as you notice, break many things. However, you could
> >easily get around this through quoting. While that would not be exactly
> >adherent to the standard, it's easier that re-writing the parser.
> >
> >In some ways, it seems to me that SQL/XML might be better defined as a
> >separate interface to the database; that is, it's own "shell" which is
> >incompatible with SQL (since the committee seems to have deliberately made it
> >incompatible).
> >
> >Thoughts?
> >
> >
> >
>
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
