Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-21 Thread Bruce Momjian
Peter Geoghegan wrote: 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

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-21 Thread Joshua Berkus
Bruce, I don't see any of this reaching the level that it needs to be backpatched, so I think we have to accept that this will be 9.2-only change. Agreed. If users encounter issues with the prefix in the field, it will be easy enough for them to back-patch. But we don't want to be

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-17 Thread Peter Geoghegan
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

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-17 Thread Robert Haas
On Thu, Nov 17, 2011 at 10:44 AM, Peter Geoghegan pe...@2ndquadrant.com wrote: 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

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-17 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: At the same time, I still think we should push this out to PGXN or pgfoundry or something. The fact that it's useful to some people does not mean that it's a good example for other people to follow, or that we want the core distribution to be in the

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-16 Thread Josh Berkus
On 11/15/11 7:40 PM, Tom Lane wrote: Peter Geoghegan pe...@2ndquadrant.com writes: If we can't put isn out of its misery, a sensible compromise would be to rip out the prefix enforcement feature so that, for example, ISBN13 behaved exactly the same as EAN13. That might be a reasonable

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-16 Thread Tom Lane
Josh Berkus j...@agliodbs.com writes: On 11/15/11 7:40 PM, Tom Lane wrote: Peter Geoghegan pe...@2ndquadrant.com writes: If we can't put isn out of its misery, a sensible compromise would be to rip out the prefix enforcement feature so that, for example, ISBN13 behaved exactly the same as

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-16 Thread Josh Berkus
(I'm a bit concerned about the angle that the code has some smarts currently about where to put hyphens in output. If we rip that out it could definitely break application code, whereas dropping a check shouldn't.) Right. Do we need to dump the hyphen logic? -- Josh Berkus PostgreSQL

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-16 Thread Peter Geoghegan
On 17 November 2011 02:32, Josh Berkus j...@agliodbs.com wrote: (I'm a bit concerned about the angle that the code has some smarts currently about where to put hyphens in output.  If we rip that out it could definitely break application code, whereas dropping a check shouldn't.) Right.  Do

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-16 Thread Tom Lane
Peter Geoghegan pe...@2ndquadrant.com writes: On 17 November 2011 02:32, Josh Berkus j...@agliodbs.com wrote: Right. Do we need to dump the hyphen logic? Only if you think that it's better to have something that covers many cases but is basically broke. Perhaps it's different for code that

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-16 Thread Josh Berkus
On 11/16/11 7:54 PM, Tom Lane wrote: 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. This is why I mentioned clients using ISBN in production. I have

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Josh Berkus
Submit a patch to fix it then. It's not fixable. The ISBN datatype is the equivalent of having an SSN datatype that only allows SSNs that have actually been assigned to a US citizen. Nothing is not fixable. not fixable without breaking backwards compatibility is entirely possible,

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Peter Geoghegan
On 15 November 2011 19:01, Josh Berkus j...@agliodbs.com wrote: Nothing is not fixable. My idea of fixing contrib/isn would be to remove so much of it that it would obviously make more sense to use simple, flexible SQL. It simply makes way too many assumptions about the user's business rules for

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Robert Haas
On Tue, Nov 15, 2011 at 2:01 PM, Josh Berkus j...@agliodbs.com wrote: Submit a patch to fix it then. It's not fixable.  The ISBN datatype is the equivalent of having an SSN datatype that only allows SSNs that have actually been assigned to a US citizen. Nothing is not fixable.  not fixable

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Kevin Grittner
Robert Haas robertmh...@gmail.com wrote: Josh Berkus j...@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

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Tom Lane
Josh Berkus j...@agliodbs.com writes: The thing is, most of the extensions in /contrib have major flaws, or they would have been folded in to the core code by now. CITEXT doesn't support multiple collations. INTARRAY and LTREE have inconsistent operators and many bugs. CUBE lacks

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Peter Geoghegan
On 15 November 2011 21:53, Tom Lane t...@sss.pgh.pa.us wrote: There's a larger issue here, which is that a lot of the stuff in contrib is useful as (a) coding examples for people to look at, and/or (b) test cases for core-server functionality.  If a module gets kicked out to PGXN we lose

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Robert Haas
On Tue, Nov 15, 2011 at 6:44 PM, Peter Geoghegan pe...@2ndquadrant.com wrote: On 15 November 2011 21:53, Tom Lane t...@sss.pgh.pa.us wrote: There's a larger issue here, which is that a lot of the stuff in contrib is useful as (a) coding examples for people to look at, and/or (b) test cases for

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Peter Geoghegan
On 15 November 2011 23:57, Robert Haas robertmh...@gmail.com wrote: We can't go on complaining one the one hand that people don't install postgresql-contrib, and then on the other hand insist on shipping really bad code in contrib.  It's asking a lot for someone who isn't already heavily

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Joshua Berkus
All, I agree. The argument that this code is useful as example code has been offered before, but the justification is pretty thin when the example code is an example of a horrible design that no one should ever copy. People are already using ISN (or at least ISBN) in production. It's been

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Peter Geoghegan
On 16 November 2011 01:09, Joshua Berkus j...@agliodbs.com wrote: People are already using ISN (or at least ISBN) in production.  It's been around for 12 years. contrib/isn has been around since 2006. The argument some unknowable number of people are using this feature in production could

Re: [HACKERS] ISN was: Core Extensions relocation

2011-11-15 Thread Tom Lane
Peter Geoghegan pe...@2ndquadrant.com writes: If we can't put isn out of its misery, a sensible compromise would be to rip out the prefix enforcement feature so that, for example, ISBN13 behaved exactly the same as EAN13. That might be a reasonable compromise. Certainly the check-digit