Re: Commitfest Status: Sudden Death Overtime

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

In response to

Responses

Browse pgsql-hackers by date

  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