Re: xpath not a good replacement for xpath_string

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql(at)mohawksoft(dot)com
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Kevin Grittner <kevin(dot)grittner(at)wicourts(dot)gov>
Subject: Re: xpath not a good replacement for xpath_string
Date: 2009-07-29 19:12:04
Message-ID: 4A709F04.5070301@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

pgsql(at)mohawksoft(dot)com wrote:
>
> Well, the API is there, it is where, I guess, PostgreSQL is going, but I
> think, philosophically, the API needs to see the XML contained within SQL
> columns as being able to represent variable and optional columns in object
> oriented environments easily. The harder it is to use a feature, the less
> usable the feature is.
>
> Do you disagree?
>
>

There is always a degree of tradeoff between power and ease of use. But
whether or not you like the way the xpath() function now works hardly
matters - we're not going to change the behaviour of an existing
function except to fix a bug.

As I said upthread, I think we can easily provide some extra convenience
functions which will do what you want. The only thing I was really
arguing about was the function name for such a gadget.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-29 21:00:20 Re: WIP: Deferrable unique constraints
Previous Message Tom Lane 2009-07-29 19:00:58 Re: date_part()/EXTRACT(second) behaviour with time data type