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 respo
Peter Geoghegan wrote:
> On 17 November 2011 03:54, Tom Lane 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 ru
Robert Haas 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
On Thu, Nov 17, 2011 at 10:44 AM, Peter Geoghegan 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 valida
On 17 November 2011 03:54, Tom Lane 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 ca
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 hav
Peter Geoghegan writes:
> On 17 November 2011 02:32, Josh Berkus 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
On 17 November 2011 02:32, Josh Berkus 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
> (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
Josh Berkus writes:
> On 11/15/11 7:40 PM, Tom Lane wrote:
>> Peter Geoghegan 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 rea
On 11/15/11 7:40 PM, Tom Lane wrote:
> Peter Geoghegan 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. Certa
Peter Geoghegan 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
On 16 November 2011 01:09, Joshua Berkus 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
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 be
On 15 November 2011 23:57, Robert Haas 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
On Tue, Nov 15, 2011 at 6:44 PM, Peter Geoghegan wrote:
> On 15 November 2011 21:53, Tom Lane 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
On 15 November 2011 21:53, Tom Lane 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
Josh Berkus 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 i
Robert Haas wrote:
> Josh Berkus 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.
>
> Wel
On Tue, Nov 15, 2011 at 2:01 PM, Josh Berkus 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 wi
On 15 November 2011 19:01, Josh Berkus 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 mo
>> 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 possibl
22 matches
Mail list logo
