From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commitfest Status: Sudden Death Overtime |
Date: | 2011-07-20 22:21:10 |
Message-ID: | 7BF90384-40A8-4AF0-A9F1-8F1374714903@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul20, 2011, at 23:35 , Tom Lane wrote:
> I find your argument against XPATH_STRING() a bit unconvincing.
> The use case for that is not where you are trying to evaluate an
> unknown, arbitrary XPath expression; it's where you are evaluating an
> expression that you *know* returns string (ie, it has name() or some
> other string returning function at top level) and you'd like a string,
> thanks, not something that you have to de-escape in order to get a
> string.
Hm, maybe I didn't make myself clear. I'm not against having
special-case functions like XPATH_STRING() at all, as long as there's
a general-purpuse function like XPATH() that deal with every expression
you throw at it.
There's a small additional concern, though, which is that there's an
XPath 2.0 spec out there, and it modifies the type system and data model
rather heavily. So before we go adding functions, it'd probably be wise
to check that we're not painting ourselves into a corner.
> Of course this use-case could also be addressed by providing a de-escape
> function, but I don't really think that de_escape(xpath(...)[1]) is a
> particularly friendly or efficient notation.
Yeah, that's pretty ugly. Having XMLESCAPE/XMLUNESCAPE (with types
TEXT -> XML and XML -> TEXT) would probably still be a good idea though,
even if it no replacement for XPATH_STRING().
> Now, these statements are not arguments against the patch --- as is,
> XPATH() is entirely useless for expressions that return scalars, and
> with the patch it at least does something usable. So I think we should
> apply it.
Cool, so we're on the same page.
> But there is room here for more function(s) to provide more
> convenient functionality for the special case of expressions returning
> strings. I'd be inclined to provide xpath_number and xpath_bool too,
> although those are less essential since a cast will get the job done.
No objection here. I do have a number of XML-related stuff that I'd like
to do for 9.2, actually. I'll write up a proposal once this commit-fest
is over, and I'll include XPATH_STRINGS and friends.
> There's some code-style aspects I don't care for in the submitted patch,
> but I'll go clean those up and commit it.
I'd offer to fix them, but I somehow have the feeling that you're already
in the middle of it ;-)
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-07-20 22:23:35 | Re: Commitfest Status: Sudden Death Overtime |
Previous Message | Robert Haas | 2011-07-20 22:08:02 | Re: [v9.1] sepgsql - userspace access vector cache |