Re: ISN was: Core Extensions relocation - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: ISN was: Core Extensions relocation
Date
Msg-id 4EC27E420200002500042F8B@gw.wicourts.gov
Whole thread Raw
In response to Re: ISN was: Core Extensions relocation  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> Josh Berkus <josh@agliodbs.com> wrote:
>> Nothing is "not fixable".  "not fixable without breaking
>> backwards compatibility" is entirely possible, though.  If fixing
>> it led to two different versions of ISN, then that would be a
>> reason to push it to PGXN instead of shipping it.
> 
> Well, the way to fix it would be to publish a new version of
> PostgreSQL every time the international authority that assigns
> ISBN prefixes allocates a new one, and for everyone to then update
> their PostgreSQL installation every time we do that.  That
> doesn't, however, seem very practical.
Having just taken a closer look at contrib/isn, I'm inclined to
think the current implementation is pretty hopeless.  ISBN seems
common enough and standardized enough that it could perhaps be
included in contrib with the proviso that ranges would only be
validated through pointing to a copy of the XML provided by the
standards body -- it wouldn't be up to PostgreSQL to supply that.
The other types in contrib/isn are things I don't know enough about
to have an opinion, but it seems a little odd to shove them all
together.  It would seem more natural to me to have a distinct type
for each and, if needed, figure out how to get a clean union of the
types.
-Kevin


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: patch for type privileges
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Unremovable tuple monitoring