Re: Imperfect solutions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Imperfect solutions
Date
Msg-id 10588.991318056@sss.pgh.pa.us
Whole thread Raw
In response to Re: Imperfect solutions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Imperfect solutions
Non-ASCII locales (was:Re: Imperfect solutions)
Re: Imperfect solutions
Re: Imperfect solutions
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What got me thinking about this is that I don't think my gram.y fix
> would be accepted given the current review process,

Not to put too fine a point on it: the project has advanced a long way
since you did that code.  Our standards *should* be higher than they
were then.

> and that is bad
> because we would have to live with no LIKE optimization for 1-2 years
> until we learned how to do it right.

We still haven't learned how to do it right, actually.  I think the
history of the LIKE indexing problem is a perfect example of why fixes
that work for some people but not others don't survive long.  We put out
several attempts at making it work reliably in non-ASCII locales, but
none of them have withstood the test of actual usage.

> I think there are a few rules we can use to decide how to deal with
> imperfect solutions:

You forgot

* will the fix institutionalize user-visible behavior that will in the long run be considered the wrong thing?

* will the fix contort new code that is written in the same vicinity, thereby making it harder and harder to replace as
timegoes on?
 

The first of these is the core of my concern about %TYPE.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Imperfect solutions
Next
From: Jan Wieck
Date:
Subject: Re: Support for %TYPE in CREATE FUNCTION