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?
>
>
>
