Обсуждение: Re: [GENERAL] Limitation

-----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

On Fri, 25 Jun 1999, John Huttley wrote:

    Heh, that sounds kinda pleasant...it's so good you mistook it for
a commercial RDBMS.  :)

# 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.

    I've often thought about donig some work on the BLOB support, the
backend storage parts, but for my main project that would use them, I've
got pretty far into splitting and encoding the data.  That's actually how
we do it in our Sybase databases because BLOBs are just too hard to deal
with with regards to replication, etc...

--
SA, beyond.com           My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

> 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.

This is on 6.6 item list.

>
> 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 is this one.



--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026