On Fri, May 29, 2015 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.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
