Hi Jim, On Mon, Nov 11, 2024 at 2:43 PM Jim Jones <jim.jo...@uni-muenster.de> wrote: > > The only thing I found during a quick perusal of the documentation was > > XMLTABLE(), which seems a bit baroque if you just want to convert one > > value. Is this intended to plug that gap? Is there any other current > > way of doing it? > > > > Do we need to ensure some kind of consistency between XMLTABLE() and > > XMLCAST() in terms of how they behave? > > I haven't considered any compatibility to XMLTABLE(), as it has a > different spec (X300-X305), but I can take a look at it! To implement > this function I just followed the SQL/XML spec "ISO/IEC IWD 9075-14" - > and from time to time I also took a look on how other databases > implemented it.[1]
Those are good things to check, but we also need to consider how it interacts with features PostgreSQL itself already has. In particular, I'm concerned about the special handling you seem to have for times and intervals. That handling might be different from what, say, XMLTABLE() does. In a perfect world, we'd probably like the features to share code, unless there is some good reason to do otherwise. But at the very least we want them to work in compatible ways. For example, if the way you convert a date into the JSON-preferred format happened to use slightly different time zone handling than the way that some other existing feature does it, that would be extremely sad. Or if the existing features don't have interval handling and you do, perhaps we ought to add that capability to the existing features and then have your new feature call the same code so that it works the same way. I haven't researched what the exact situation is here too and these examples I'm giving you here are strictly hypothetical -- they're just the kind of thing that needs to be sorted out before we can think about committing anything. There's still also the question of desirability. I take it for granted that you want this feature and consider it valuable, but sometimes people submit patches for a feature that only the submitter wants and nobody else cares about it (or even, other people actively dislike it). I am in a very poor position to assess how important this feature is or to what extent it complies with the relevant specification. Vik, who I see you copied, is probably in a much better position to interpret the spec than I am, and may or may not also know something about whether people want this. I continue to hope that we'll get some comments from others as well. -- Robert Haas EDB: http://www.enterprisedb.com
