From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Imperfect solutions |
Date: | 2001-05-31 14:07:36 |
Message-ID: | 10588.991318056@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2001-05-31 14:15:18 | Re: Support for %TYPE in CREATE FUNCTION |
Previous Message | Bruce Momjian | 2001-05-31 14:03:21 | Re: Imperfect solutions |