Re: [GENERAL] Limitation

-----Original Message-----
From: Dustin Sallings <dustin(at)spy(dot)net>
To: John Huttley <john(at)mwk(dot)co(dot)nz>
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>; pgsql-general
<pgsql-general(at)postgreSQL(dot)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