On Tue, Nov 15, 2011 at 6:44 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 15 November 2011 21:53, Tom Lane <tgl@sss.pgh.pa.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