Re: [HACKERS] Happy column dropping - Mailing list pgsql-hackers

On Sun, 23 Jan 2000, Hannu Krosing wrote:

> The current "(UN)Happy column dropping" discussion, frankly seems to
> stem much from jealousy - hands off my tree, we allow only _purfect_
> contributions.

I don't expect any contribution to be perfect ... I do expect those that
are committing code directly to the source tree to take a few minutes and
think before they do so.  Peter *knew* there were implementation flaws to
what he added, yet he implemented it anyway, without asking anyone else
for comments and/or suggestions on how those flaws could be avoided ... if
Peter didn't have commit access, he would have had to submit those patches
for review before having them applied, just like Alfred recently went
through with his libpq changes ...

> OTOH there are several existing features in postgresql you would not
> expect, unless you have worked with postgresql for many years and read
> most of traffic on hackers list (like running out of almost all
> resources doing a seemingly innocent query (or having it done for you
> by a "smart"  application), or lack of most common-sense "convenience"
> optimisations, like using index for max(), or being able to
> _partially_ rollback DDL statements.

Ah, but, in these cases, they lack of don't break existing applications
*and* the running out of all resources definitely isn't "hidden" in the
background, you find out about it quick ...

The beef I have with how Peter went about implementing this was that the
biggest flaw that he lists is *hidden* in the background ... 

> Nobody has demanded removing ORs (or even the optimiser ;)) from
> postgres because they can explode the backend.

It is because they explode the backend that we don't ... what Peter
implemented silently tromps on the OIDs ...

> So IMHO discouraging small usability improvements is wrong.

Ppl are missing the whole point here ... it isn't the improvement that I
have a beef against, it is the fact that, unlike every other feature
addition (bug fixes are different), there was absolutely no discussion
before implementation ... hell, if the implementation didn't come with a
"caveat" afterwards, it wouldn't have been so bad, but Peter commit'd a
"small usability improvement" followed up by what *I* consider to be one
helluva caveat, without any discussion on how to get around that before
committing ... that, IMHO, is wrong ...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org