Re: [HACKERS] Happy column dropping

Don Baccus wrote:
> 
> At 12:27 AM 1/23/00 -0500, Tom Lane wrote:
> 
> >I'm of two minds about this.  Peter is an energetic new contributor
> >and we'd be really foolish to discourage him (I was there not very
> >long ago myself).  And a limited DROP COLUMN capability is better
> >than none at all, so long as its limitations are well-documented.
> >
> >OTOH, I understand Don Baccus' concern: Postgres is on the cusp of
> >being considered professional-grade software --- we are competing
> >against multi-K-dollar commercial offerings --- and we jeopardize
> >that perception if we add features that are less than fully baked.
> >This is definitely in the 50%-baked category...
> 
> I certainly don't want to discourage Peter, either, and perhaps
> was a bit too harsh.  But release of a feature this half-baked

Putting something in a development tree can hardly be called a "release"
I'm sure many people would appreciate it even without "preserving oid-s" 
as OID's are declared deprecated for (AFAIK) >2 years, and they don't give 
any real advantage over primary key with default nextval, as there are 
currently no means for reasonably getting from oid to record.

I agree that it could be #ifedef'ed or usable only when you do:
set TerribleDropColumnCludge to 'ON';

> would fit the stereotype many people have held towards free,
> open source software, and postgres in particular.

What keeps us from discussing the implementation _now_ that we have something 
to discuss. Much of the success of open source software comes from the 
"show me the code" mentality - you discuss what you have, not what you might
do.

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

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.

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

So IMHO discouraging small usability improvements is wrong.

> IMHO, of course.

Sure

--------------------
Hannu