Re: [HACKERS] ISN was: Core Extensions relocation
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 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. Clarification: Our policy for patching back-branches is that the bug has to affect many users, be serious, and the fix has to be easily tested. For a user-visible change (which this would be), the criteria is even more strict. 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. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 responsible for it as a project. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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
Re: [HACKERS] ISN was: Core Extensions relocation
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 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. Well, keep in mind that most people test their code. It seems likely that it actually DOES work pretty well for the people who are using the module. The ones for whom it didn't work presumably would have complained (and, mostly, they haven't) or abandoned the module (in which case they're irrelevant to the discussion of who might be hurt by this change). I'd be willing to bet a nickle that we'll get complaints if we rip that hyphenation behavior out. 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 process of tracking ISBN prefixes on behalf of PostgreSQL users everywhere. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 process of tracking ISBN prefixes on behalf of PostgreSQL users everywhere. I wouldn't object to that as long as we replaced it with some other module that had a similar relationship to core types. We'd never have realized the need for CREATE TYPE's LIKE option, until it was far too late, if we'd not had contrib/isn to show up the problem (cf commit 3f936aacc057e4b391ab953fea2ffb689a12a8bc). But really I think this discussion is making a mountain out of a molehill. If tracking ISBN prefix changes is such a time-consuming activity, why have we not seen a steady stream of update patches from users? By my count there's been just one such patch since 2006 (commit 6d1af7b2180719102a907bd3e35d218b43e76ad1). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 compromise. Certainly the check-digit calculation is much more useful for validity checking than the prefix checking. Sounds good to me. FWIW, I know that ISBN is being used for some library software, so a backwards-compatible fix would be very desirable. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 EAN13. That might be a reasonable compromise. Certainly the check-digit calculation is much more useful for validity checking than the prefix checking. Sounds good to me. FWIW, I know that ISBN is being used for some library software, so a backwards-compatible fix would be very desirable. How backwards-compatible do you mean? Do you think we need to keep the existing prefix-check logic as an option, or can we just drop it and be done? (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.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
(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 Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 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 is already committed, but in the case of new submissions it tends to be better to have something that is limited in a well-understood way rather than less limited in a way that is unpredictable or difficult to reason about. -- 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
Re: [HACKERS] ISN was: Core Extensions relocation
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 is already committed, but in the case of new submissions it tends to be better to have something that is limited in a well-understood way rather than less limited in a way that is unpredictable or difficult to reason about. Well, as was stated upthread, we might have bounced this module in toto if it were submitted today. But contrib/isn has been there since 2006, and its predecessor contrib/isbn_issn was there since 1998, and both of those submissions came from (different) people who needed the functionality bad enough to write it. It's not reasonable to suppose that nobody is using it today. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 yet to see any actual breakage in the field. Granted, both clients are US-only. I don't believe either of these clients is depending on the prefix-check, and that's the sort of thing we could announce in the release notes. 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. ;-) -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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, 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. It's not as if ISN is poorly coded. This is a spec issue, which must have been debated when we first included it. No? That's exactly why contrib is a random amalgamation of really useful stuff and utter crap: people feel justified in defending the continued existence of the crap on the sole basis that it's useful to them personally. Why else would we justify anything? It's very difficult to argue on the basis of theoretical users. How would we really know what a theoretical user wants? Calling something crap because it has a spec issue is unwarranted. We're going to get nowhere in this discussion as long as people are using extreme and non-descriptive terms. 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 documentation. DBlink is an ongoing battle with security holes. etc. Picking out one of those and saying this is crap because of reason X, but I'll ignore all the flaws in all these other extensions is inconsistent and not liable to produce results. Now, if you wanted to argue that we should kick *all* of the portable extensions out of /contrib and onto PGXN, then you'd have a much stronger argument. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 a generic C module. Calling something crap because it has a spec issue is unwarranted. We're going to get nowhere in this discussion as long as people are using extreme and non-descriptive terms. It is warranted, because contrib/isn is extremely wrong-headed. 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 documentation. DBlink is an ongoing battle with security holes. etc. The difference is that it's possible to imagine a scenario under which I could recommend using any one of those modules, despite their flaws. I could not contrive a reason for using contrib/isn. -- 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
Re: [HACKERS] ISN was: Core Extensions relocation
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 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. It just doesn't make sense to define a datatype where the set of legal values changes over time. The right place to put such constraints in the application logic, where it doesn't take a database upgrade to fix the problem. It's not as if ISN is poorly coded. This is a spec issue, which must have been debated when we first included it. No? I think our standards for inclusion have changed over the years - a necessary part of project growth, or we would have 500 contrib modules instead of 50. The original isbn_issn module was contributed in 1998; it was replaced by contrib/isn in 2006 because the original module became obsolete. I think it's fair to say that if this code were submitted today it would never get accepted into our tree, and the submitter would be advised not so much to publish on PGXN instead as to throw it away entirely and rethink their entire approach to the problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 documentation. DBlink is an ongoing battle with security holes. etc. Picking out one of those and saying this is crap because of reason X, but I'll ignore all the flaws in all these other extensions is inconsistent and not liable to produce results. Now, if you wanted to argue that we should kick *all* of the portable extensions out of /contrib and onto PGXN, then you'd have a much stronger argument. 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 pretty much all the advantages of (b), and some of the value of (a) because stuff that is in the contrib tree at least gets maintained when we make server API changes. So the fact that a module has conceptual flaws that are preventing it from getting moved into core doesn't really have much to do with whether we should remove it, IMV. The big question to be asking about ISN is whether removing it would result in a loss of test coverage for the core server; and I believe the answer is yes --- ISTR at least one bug that we found specifically because ISN tickled it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 pretty much all the advantages of (b), and some of the value of (a) because stuff that is in the contrib tree at least gets maintained when we make server API changes. The isn module is patently broken. It has the potential to damage the project's reputation if someone chooses to make an example out of it. I think that that's more important than any additional test coverage it may bring. There's only a fairly marginal benefit at the expense of a bad user experience for anyone who should use isn. -- 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
Re: [HACKERS] ISN was: Core Extensions relocation
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 core-server functionality. If a module gets kicked out to PGXN we lose pretty much all the advantages of (b), and some of the value of (a) because stuff that is in the contrib tree at least gets maintained when we make server API changes. The isn module is patently broken. It has the potential to damage the project's reputation if someone chooses to make an example out of it. I think that that's more important than any additional test coverage it may bring. There's only a fairly marginal benefit at the expense of a bad user experience for anyone who should use isn. 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. I don't see that the isn code is doing anything that is so unique that one of our add-on data types wouldn't be a suitable (probably far better) template, but if it is, let's add similar functionality to some other module, or add a new module that does whatever that interesting thing is, or shove some code in src/test/examples. 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 involved in the project to distinguish the wheat from the chaff. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 involved in the project to distinguish the wheat from the chaff. ISTM that any sensible sanitisation of data guards against Murphy, not Machiavelli. Exactly what sort of error is it imagined will be prevented by enforcing that ISBN prefixes are valid? Transcription and transposition errors are already guarded against very effectively by the check digit. 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 would at least result in predictable behaviour. The strike that separates each part of the ISBN would be lost, but it is actually not visible on large ISBN websites, presumably because it's a tar-pit of a problem. -- 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
Re: [HACKERS] ISN was: Core Extensions relocation
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 around for 12 years. So any step we take with contrib/ISN needs to take that into account -- just as we have with Tsearch2 and XML2. One can certainly argue that some of the stuff in /contrib would be better on PGXN. But in that case, it's not limited to ISN; there are several modules of insufficient quality (including intarray and ltree) or legacy nature which ought to be pushed out. Probably most of them. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ISN was: Core Extensions relocation
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 equally well apply to anything that we might consider deprecating. I am not arguing for putting isn on PGXN. I'm arguing for actively warning people against using it, because it is harmful. Any serious use of the ISBN datatypes can be expected to break unpredictably one day, and the only thing that someone can do in that situation is to write their own patch to contrib/isn. They'd then have to wait for that patch to be accepted if they didn't want to fork, which is a very bad situation indeed. This already happened once. -- 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
Re: [HACKERS] ISN was: Core Extensions relocation
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 calculation is much more useful for validity checking than the prefix checking. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
