Re: [HACKERS] Happy column dropping
От | Don Baccus |
---|---|
Тема | Re: [HACKERS] Happy column dropping |
Дата | |
Msg-id | 3.0.1.32.20000123110141.01061b90@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Happy column dropping (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: [HACKERS] Happy column dropping
(The Hermit Hacker <scrappy@hub.org>)
|
Список | pgsql-hackers |
At 08:53 PM 1/23/00 +0200, Hannu Krosing wrote: >What keeps us from discussing the implementation _now_ that we have something >to discuss. Nothing. The argument is simply that perhaps discussion should come FIRST. > 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. I see a lot of pre-implementation discussion on this group. For instance, recently there was public discussion of "TOAST" large data types. Details were ironed out, now Jan will go implement it when he has time. Likewise his approach to implementing referential integrity was discussed here beforehand. Just today, we're seeing discussion of the implementation of a new stddev aggregate function. I think this is a good process to follow. >The current "(UN)Happy column dropping" discussion, frankly seems to stem much >from jealousy - hands off my tree, we allow only _purfect_ contributions. Are you suggesting that the goal should be anything less than perfection? I guess this goes to my argument that Postgres is starting to be regarded as a potential competitor to expensive commercial DBs in certain application environments. If the bar is lowered for contributions, Postgres will quickly re-earn the image of flakiness that the current developers have worked so hard to shed. >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. No ... but fixing ORs seems to be on the list of things to be done. Pointing to the fact that the inherited code still needs a lot of work before it's really a solid, commercial-quality database engine in all regards doesn't convince me that weak implementations of new features should be added. My impression is that the current crop of developers are aiming higher... - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: