Re: RFC: Remove contrib entirely

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Remove contrib entirely
Date: 2015-05-29 21:51:42
Message-ID: CAM3SWZQox9UOPPF6wr25ZY8g91+EN9TbdB=EOdj6JNAchXaz-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 29, 2015 at 2:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> It made us realize that extensions that create types
> that are physically equivalent to int8 or float8 were broken when we made
> those types potentially pass-by-value; we had to add a CREATE TYPE option
> to allow that to still work (cf commit 3f936aacc057e4b3). If contrib/isn
> had not been around and been getting built by the buildfarm, we would have
> found that out only much later and with much more pain.

Interesting.

FWIW, my concerns with contrib/isn are limited to the ISBN type and
related types. These types enforce that ISBNs are within certain
ranges known by the module to be valid. The first patch I reviewed for
Postgres back in 2010 extended this range, and I first raised the
issue then -- how many such patches can we expect in the future?

The problem here is that these ranges are controlled by a
decentralized patchwork of national standards bodies, and the ranges
are always subject to revision. I think that it's egregious that
contrib/isn imagines it can track that with a static array.

Since contrib is a place that example code is supposed to live,
perhaps contrib/isn could be held up as an example of what not to
do...
--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-29 21:54:51 Re: RFC: Remove contrib entirely
Previous Message Tom Lane 2015-05-29 21:37:13 Re: [CORE] postpone next week's release