Prev: plperl compiler warning
Next: [HACKERS] returning array in a field together with other types
From: Alvaro Herrera on 28 Jan 2010 22:00
Robert Haas escribi�:
> On Thu, Jan 28, 2010 at 5:54 PM, Josh Berkus <josh(a)agliodbs.com> wrote:
> >> Yeah, we can't really remove it until we have a plausible substitute for
> >> the xpath_table functionality. �This is in the TODO list ...
> >
> > What about moving it to pgfoundry?
> >
> > I'm really not keen on shipping known-broken stuff in /contrib.
>
> Yeah, exactly. Another option - if we know that it works OK with
> inputs of certain types - might be to throw an error if we get an
> input of a type we know it doesn't work with. But I guess I haven't
> followed this closely enough to know exactly what kinds of arguments
> do/don't work.

If it were easy to throw an error, it'd be better to avoid the crash.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 1 Feb 2010 13:28
On Thu, Jan 28, 2010 at 5:41 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew(a)dunslane.net> writes:
>> Robert Haas wrote:
>>> I think we need to either (1) fix the bugs and update the
>>> documentation to remove the statement that this will be removed or (2)
>>> actually remove it.
>
>> I agree it's a mess but I don't think just abandoning the functionality
>> is a good idea.
>
> Yeah, we can't really remove it until we have a plausible substitute for
> the xpath_table functionality.  This is in the TODO list ...

My feeling is that if it's as flakey and unreliable as it currently
is, we shouldn't ship it. Removing it from CVS doesn't mean "you
can't use this any more"; this is open source. It just means people
will have to go and get an old copy out of CVS and presumably in so
doing they will be aware that we've removed it for a reason. We have
a well-deserved reputation for quality and I would like to see us
preserve that.

Is anyone going to try to fix this for 9.0?

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 1 Feb 2010 13:38
Robert Haas <robertmhaas(a)gmail.com> writes:
> My feeling is that if it's as flakey and unreliable as it currently
> is, we shouldn't ship it. Removing it from CVS doesn't mean "you
> can't use this any more"; this is open source. It just means people
> will have to go and get an old copy out of CVS and presumably in so
> doing they will be aware that we've removed it for a reason. We have
> a well-deserved reputation for quality and I would like to see us
> preserve that.

[ shrug... ] It is not any more flaky than it's been since it was put in.
The people who have been depending on it presumably have use-patterns
for which it doesn't fail, and we're not going to be doing them a
service by ripping out functionality for which we can't offer a
replacement.

As for the "quality" argument, contrib modules are not guaranteed
to be of the same standard as the core code; anyone who thinks they are
should disabuse themselves of the notion by reading some of that code.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 1 Feb 2010 13:48
On Mon, Feb 1, 2010 at 1:38 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
>> My feeling is that if it's as flakey and unreliable as it currently
>> is, we shouldn't ship it.  Removing it from CVS doesn't mean "you
>> can't use this any more"; this is open source.  It just means people
>> will have to go and get an old copy out of CVS and presumably in so
>> doing they will be aware that we've removed it for a reason.  We have
>> a well-deserved reputation for quality and I would like to see us
>> preserve that.
>
> [ shrug... ]  It is not any more flaky than it's been since it was put in.
> The people who have been depending on it presumably have use-patterns
> for which it doesn't fail, and we're not going to be doing them a
> service by ripping out functionality for which we can't offer a
> replacement.

Well, then we'd at least better update the documentation to (1) remove
the statement that this will be removed in 8.4 (since we didn't), and
(2) add a very, very large warning that this will crash if you do
almost anything with it.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on 1 Feb 2010 17:23


Robert Haas wrote:
> (2) add a very, very large warning that this will crash if you do
> almost anything with it.
>
>
>

I think that's an exaggeration. Certain people are known to be using it
quite successfully.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: plperl compiler warning
Next: [HACKERS] returning array in a field together with other types