On 17 November 2011 03:54, Tom Lane <t...@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 <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
