Re: ISN was: Core Extensions relocation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ISN was: Core Extensions relocation
Date: 2011-11-15 23:57:51
Message-ID: CA+Tgmob+dkA5nPP2QqjzNauH+R2-0Bm8c81ehTB3iXdEh9cQLA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 15, 2011 at 6:44 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> On 15 November 2011 21:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> There's a larger issue here, which is that a lot of the stuff in contrib
>> is useful as (a) coding examples for people to look at, and/or (b) test
>> cases for core-server functionality.  If a module gets kicked out to
>> PGXN we lose pretty much all the advantages of (b), and some of the
>> value of (a) because stuff that is in the contrib tree at least gets
>> maintained when we make server API changes.
>
> The isn module is patently broken. It has the potential to damage the
> project's reputation if someone chooses to make an example out of it.
> I think that that's more important than any additional test coverage
> it may bring. There's only a fairly marginal benefit at the expense of
> a bad user experience for anyone who should use isn.

I agree. The argument that this code is useful as example code has
been offered before, but the justification is pretty thin when the
example code is an example of a horrible design that no one should
ever copy. I don't see that the isn code is doing anything that is so
unique that one of our add-on data types wouldn't be a suitable
(probably far better) template, but if it is, let's add similar
functionality to some other module, or add a new module that does
whatever that interesting thing is, or shove some code in
src/test/examples. We can't go on complaining one the one hand that
people don't install postgresql-contrib, and then on the other hand
insist on shipping really bad code in contrib. It's asking a lot for
someone who isn't already heavily involved in the project to
distinguish the wheat from the chaff.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2011-11-16 00:14:36 Re: strict aliasing
Previous Message Josh Kupershmidt 2011-11-15 23:54:30 psql \ir filename normalization