Skip site navigation (1) Skip section navigation (2)

xpath improvement V2

From: Arie Bikker <arie(at)abikker(dot)nl>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Scott Bailey <artacus(at)comcast(dot)net>, robertmhaas(at)gmail(dot)com, wulczer(at)wulczer(dot)org
Subject: xpath improvement V2
Date: 2010-02-12 21:32:08
Message-ID: 4B75C8D8.8090509@abikker.nl (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi all,

I've combined the review suggestions of Jan Urbański, Scott Bailey, and
others.
This was a lot harder, then I had foreseen; and I took my time to do it
the right way (hope you agree!).

BTW. really appreciate your efforts, so far, to enlighten me on nuub 
errors/mistakes in the previous version.

Additional improvement (hence the V2):
two extra functions: xpath_value_text and xpath_value_strict
Both are quite general: xpath_value_text maps everything to text, except 
nodeset. xpath_value_strict has to be told exactly what to expect.
xpath_value_text(text xpath, xml doc [, namespace]) returns text
xpath_value_strict(anyelement typexample, text xpath, xml doc [, 
namespace]) returns anyelement
  See the doc for further explanation.
I chose this approach, as opposed to xpath_value_string/number/boolean 
for a couple of reasons:
- We want postgresql functions, with postgresql types. The functions 
should fit postgresql usage and hide libxml parlance.
- Functions in pg_catalog should be destined for broad use, not just 
satisfy the adhoc desire of the implementer.
- Function synopsis should be adequate to withstand libxml extension or 
improvements (libxml3?)
- Construction of XPath expressions for value retrieval is not trivial. 
A precise calling syntax, hopefully, focuses the user to select the 
right expressions.
- Loose implementation with "autocasting" opens the door for unwanted 
injection possibilities.

Lastly, when in need of a xpath_value_string (et al), it can easily be 
added by the user through:
CREATE FUNCTION xpath_value_string(text, xml) RETURNS text AS $$
SELECT xpath_value_strict('a'::text,$1,$2);
$$ LANGUAGE SQL;

Points fixed:
- source code indentation. (manually though, can't get pgindent to work
properly)
- Doc entries with some examples
- test/regress entries
- Detailed directions from Jan Urbanski on ereport and PG_TRY/CATCH.

Here's a shortlist of subjects you should definetely review (aka I'me 
not certain these are up to standards)
- calling style in xpath_value_strict with typexample. I really like it,
but I haven't seen such an approach elsewhere in the API.
- tone and style in doc. I'me not native English speaker and had to 
learn DocBook along the way.
- insertion in catalog/pg_proc.h. Just took some free oid numbers, and 
fiddled the other parameters.
- Is ERRCODE_DATA_EXCEPTION (in xml.c) acceptable as error code for a 
type mismatch? Could not find anything better.

kind regards, Arie Bikker


Attachment: xmlval.patch
Description: text/x-patch (13 bytes)

Responses

pgsql-hackers by date

Next:From: Arie BikkerDate: 2010-02-12 21:49:45
Subject: Re: xpath improvement V2
Previous:From: Alex HunsakerDate: 2010-02-12 21:30:37
Subject: Re: Package namespace and Safe init cleanup for plperl [PATCH]

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group