On Fri, May 29, 2015 at 2:35 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
