Why I like partial solutions

I find myself repeatedly arguing for partial solutions, and having to
struggle with other developers who feel these solutions are hacks.
Let me explain why I like these hacks.

When we have a feature that users want, often we can't get it
implemented promptly in a clean way. It can take several releases for
someone to focus on the problem, re-factor the code, and get the feature
in there properly.

While we are waiting months, often years, for a features to be properly
implemented, our users have no solution except to wait for us to
implement it.

At the same time, there often is a way to implement the feature
partially, often unattractively, so that users can use the feature until
we get around to implementing it properly.

When I think back on many of my code contributions, a lot of them were
such hacks: temp tables, optimizer statistics, indexed LIKE in gram.y.
Many people hated that last one, and I got all sorts of grief because it
was done in such an ugly way, but it was used for years until the
feature was properly implemented in the optimizer. Same for temp tables
and optimizer statistics. That code is gone now, and that is fine. It
was easy to rip out once a proper solution was made, but it served its
purpose.

So, when we review patches, we shouldn't be turning up our noses at
imperfect solutions if the solution meets needs of our users. We had
DROP COLUMN and NO CREATE TABLE solutions suggested many years ago, and
because the solutions weren't perfect, we don't have those features, and
users who needed those features have had to move to other databases.
How many users have we lose just on those two features?

Sure, now we will have schemas in 7.3, but we could have given users _a_
solution years ago; not a prefect solution, but enough of a solution to
keep them using PostgreSQL until we implemented it properly.

Maybe this is marketing, but when people repeatedly ask for a feature,
and we can implement it with a partial solution now, I think we should
do it, rather than saying "Oh, we can't do that properly so we will just
do nothing."

If we want to grow PostgreSQL, we need to meet users needs, even if that
requires stomaching some hack solutions from time to time. That's why I
like partial solutions.

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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> So, when we review patches, we shouldn't be turning up our noses at
> imperfect solutions if the solution meets needs of our users.

I think our standards have gone up over the years, and properly so.
The fact that we put in hacks some years ago doesn't mean that we
still should.

I don't really mind hacks^H^H^Hpartial solutions that are clean subsets
of the functionality we want to have eventually. I do object to hacks
that will create a backwards-compatibility problem when we want to do it
right.

regards, tom lane

On Wed, 26 Jun 2002, Tom Lane wrote:

> I don't really mind hacks^H^H^Hpartial solutions that are clean subsets
> of the functionality we want to have eventually. I do object to hacks
> that will create a backwards-compatibility problem when we want to do it
> right.

If the backwards compatability problem is just related to stuff from the
users (i.e., this keyword works in this release, but will not work in
future releases), I don't see the problem. Just document it and move on.
The user can either use it and deal with the compatbility pain later,
or not use it and be just where he would be if the hack were never
implmemented in the first place.

Otherwise you only have to leave the feature in until the next major
release, anyway, right? Because for major releases it's expected that
you will have to dump and restore you database anyway, hmm?

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

Tom Lane wrote:
>
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > So, when we review patches, we shouldn't be turning up our noses at
> > imperfect solutions if the solution meets needs of our users.
>
> I think our standards have gone up over the years, and properly so.
> The fact that we put in hacks some years ago doesn't mean that we
> still should.
>
> I don't really mind hacks^H^H^Hpartial solutions that are clean subsets
> of the functionality we want to have eventually. I do object to hacks
> that will create a backwards-compatibility problem when we want to do it
> right.

I absolutely agree on that. If we at some point want to have a given
feature, we need to avoid backward compatibility problems.

As for features that are independent, don't break anything, just
add-on's that can happily swim around in contrib (but stay out of the
deep water), we might want to become a bit more relaxed again.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #