Re: ISN was: Core Extensions relocation

On 17 November 2011 03:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's not reasonable to suppose
> that nobody is using it today.

I didn't suppose that no one is using it, but that those that are
using it are unaware of the risks with prefix validation, and that
there will be a rude awakening for them.

> Ergo, we can't just summarily break
> backwards compatibility on the grounds that we don't like the design.
> Heck, we don't even have a field bug report that the design limitation
> is causing any real problems for real users ... so IMO, the claims that
> this is dangerously broken are a bit overblown.

I think that's it's rather unlikely that removing hyphenation and
prefix validation would adversely affect anyone, provided that it was
well documented and wasn't applied to stable branches. If it were up
to me, I might remove validation from stable branches but keep
hyphenation, while removing both for 9.2 . After all, hyphenation will
break anyway, so they're worse off continuing to rely on hyphenation
when it cannot actually be relied on.

On 17 November 2011 05:03, Josh Berkus <josh@agliodbs.com> wrote:
> I do get the feeling that Peter got burned by ISN, given his vehemence
> in erasing it from the face of the earth.  So that's one bug report.  ;-)

Actually, I reviewed a band-aid patch about a year ago, and I was
fairly concerned at the obvious wrong-headedness of something in our
tree. I have a certain amount of domain knowledge here, but I've never
actually attempted to use it in production. For all its faults, it is
at least obviously broken to someone that knows about GS1 standards
(having separate bar code datatypes is just not useful at all),
although that tends to not be Americans. This may account for why
we've heard so few complaints. It's also really easy and effective to
create your own domain, and the flexibility that this affords tends to
make an off-the-shelf solution unattractive (I've done things like
store "compacted" bar codes that will subsequently be used to match a
full bar code with an embedded price - I didn't want to enforce a
check digit for the compacted representation).

If I had a lot of time to work on fixing contrib/isn, I still
wouldn't, because the correct thing to do is to produce your own
domain.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services