Re: Commitfest Status: Sudden Death Overtime - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: Commitfest Status: Sudden Death Overtime
Date
Msg-id 7BF90384-40A8-4AF0-A9F1-8F1374714903@phlo.org
Whole thread Raw
In response to Re: Commitfest Status: Sudden Death Overtime  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Commitfest Status: Sudden Death Overtime
Re: Commitfest Status: Sudden Death Overtime
List 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




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [v9.1] sepgsql - userspace access vector cache
Next
From: Tom Lane
Date:
Subject: Re: Commitfest Status: Sudden Death Overtime