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
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 |