On Thu, May 31, 2001 at 10:07:36AM -0400, Tom Lane wrote:
> 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 time goes on?
>
> The first of these is the core of my concern about %TYPE.
This list points up a problem that needs a better solution than a
list: you have to put in questionable features now to get the usage
experience you need to do it right later. The set of prospective
features that meet that description does not resemble the set that
would pass all the criteria in the list.
This is really a familiar problem, with a familiar solution.
When a feature is added that is "wrong", make sure it's "marked"
somehow -- at worst, in the documentation, but ideally with a
NOTICE or something when it's used -- as experimental. If anybody
complains later that when you ripped it out and redid it correctly,
you broke his code, you can just laugh, and add, if you're feeling
charitable, "experimental features are not to be depended on".
--
Nathan Myers
ncm@zembu.com
