Re: [GENERAL] Limitation - Mailing list pgsql-general

From John Huttley
Subject Re: [GENERAL] Limitation
Date
Msg-id 000901bebe9c$06e81040$1401a8c0@Mr_Creosote.MWK.co.nz
Whole thread Raw
Responses Re: [GENERAL] Limitation  (Dustin Sallings <dustin@spy.net>)
Re: [GENERAL] Limitation  (Bruce Momjian <maillist@candle.pha.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Limitation
Next
From: "John Huttley"
Date:
Subject: Fsync and Linux