Re: [GENERAL] Limitation
От | John Huttley |
---|---|
Тема | Re: [GENERAL] Limitation |
Дата | |
Msg-id | 000901bebe9c$06e81040$1401a8c0@Mr_Creosote.MWK.co.nz обсуждение исходный текст |
Ответы |
Re: [GENERAL] Limitation
Re: [GENERAL] Limitation |
Список | pgsql-general |
-----Original Message----- From: Dustin Sallings <dustin@spy.net> To: John Huttley <john@mwk.co.nz> Cc: Bruce Momjian <maillist@candle.pha.pa.us>; pgsql-general <pgsql-general@postgreSQL.org> Date: Friday, 25 June 1999 10:55 Subject: Re: [GENERAL] Limitation > > Then make a trigger. Because I didn't think of it. Mind in a rut, I suppose. Your attitude towards this project would >make sense if you were a paying customer. If you want to use postgres, >then use it, nobody gets paid any less if you don't. If you want >structural changes in the database to accomodate a bad design, then you're >free to make them, you have the source. PG 6.5 is now so _good_. The previously serious limits of table locking, no subselects and no currency type are history. Its so tempting to treat it as Oracle-lite that when I hit a design limitation its a bit of a shock. Hackers need input from users, else they will never know what real world problems are occuring. I'd love to tear in there and change things, but I'm not a systems level programmer, I'm a engineer doing application coding. Understanding 'High Concurrency- Btrees', SQL grammar and semantics etc is not a thing that amateurs are equipped to do. The announcement for 6.5 implied much the same thing. 'mastery over the inherited code base'. --- after years of work. In fact, looking at the Hackers mailing list shows that most of the heavy work is done by about 4 people. Actually there are things in libpq -large object support- I will investigate. Thats very much nibbling around the edge. So lets have a look at everything again. Consider it a users wish list for 7.0 1. The 7 field index limit. Doubtless someone made a decision back in the dark ages that no-one would ever need more than that. 2. Ruleplan overflows. maybe fixing this is just changing a #define to allocate more space. 3. Parametised Stored Procedures that return record sets. This is a significant item. Commercial db's can do it. Porting modern applications to PG will require it. 4. Unlimited tuple size. I see that this is already on the list. So lets see what happens. Regards
В списке pgsql-general по дате отправления: