Re: Imperfect solutions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Imperfect solutions
Дата
Msg-id 10588.991318056@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Imperfect solutions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Imperfect solutions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Non-ASCII locales (was:Re: Imperfect solutions)  (Lamar Owen <lamar.owen@wgcr.org>)
Re: Imperfect solutions  (ncm@zembu.com (Nathan Myers))
Re: Imperfect solutions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Imperfect solutions
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: Support for %TYPE in CREATE FUNCTION