Re: Imperfect solutions

> 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.

Yes, agreed. But at the time that was the best we could do. My
question is whether we should be less willing to accept partial fixes
now than in the past. Probably yes, but have we gone too far?

Look at some of the imperfect solutions we have rejected recently, all
from the TODO list:

* Improve control over user privileges, including table creation and
lock use [privileges] (Karel, others)
* Remove unused files during database vacuum or postmaster startup
* Add table name mapping for numeric file names
* Add ALTER TABLE DROP COLUMN feature [drop]
* Cache most recent query plan(s) (Karel) [prepare]

Now that I look at it, the list is pretty short, so we may be fine.

> > 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.

Agreed. But what options do we have? If we do nothing, there is no
optimization at all.

> > 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?

Yes, good point. User-visible changes are a big deal and have to be
studied carefully.

> * 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?

Again, a good point, related to rip-out-ability.

> The first of these is the core of my concern about %TYPE.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026