Re: [INTERFACES] Re: [HACKERS] changes in 6.4 - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [INTERFACES] Re: [HACKERS] changes in 6.4 |
Date | |
Msg-id | 199807152023.QAA22244@candle.pha.pa.us Whole thread Raw |
In response to | Re: [INTERFACES] Re: [HACKERS] changes in 6.4 (Hannu Krosing <hannu@trust.ee>) |
List | pgsql-hackers |
> Bruce Momjian wrote: > > > > > > I was afraid I was going to insult someone by saying what I did. > > > > I MEANT that there are no features being added that a non-postgresql > > user would be interested in. subselects was one feature that > > non-postgresql users would understand. Most of our stuff now is > > cleanup/extension of 6.3 features, many of which would be uninteresting > > to potential users. > > Not requiring the column to sort on in target list ia also quite > important. > > As are the (still elementary) constraints, still elementary becuse > there is no way to use functions or "is null" in check constraint, > and constraints can be used only when defining tables, not in > "alter table" construct. > > > The days where every release fixed server crashes, or added a feature > > that users were 'screaming for' may be a thing of the past. > > Is anyone working on fixing the exploding optimisations for many OR-s, > at least the canonic case used by access? > > My impression is that this has fallen somewhere between > insightdist and Vadim. > > > We are nearing a maturity stage, where we can focus on performance, > > documenation, features, and cleanup. The days when we have a 'major' > > feature may be fewer, because we have added 'most' of the major features > > people have been asking for. > > Expect them asking more soon ;) > > I'm sure that soon being just basic ANSI SQL compliant is not enough; > people will want (in no particular order ;): > * ANSI CLI, > * updatable cursors, > * foreign key constraints, > * distributed databases, > * row level locking, > * better inheritance, > * domains, > * isolation levels, > * PL/SQL, > * better optimisation for special cases, > * temporary tables (both global and session level), > * more SQL3 constructs, > * unlisten command, maybe an argument to listen command, > * better support for installing your own access methods, > * separating the methods typinput/typoutput (native binary) > and typreceive/typsend (wire binary), they are in pg_type > * implementing a new fe/be protocol that is easier to implement > (does not mix zero terminated, and count-prefixed chunks), > preferrably modelled after X-Window protocol. > * getting rid of the 8k limitations, both in fe/be protocol and > in disk storage. > > I know that some of these things are being worked on, but I've lost > track which are expected for 6.4, which for 6.5 and which I should > not expect before 8.0 ;) > > > Our user base is growing, and the number of sophisticated developers is > > growing too, so we are getting major patches to improve lots of existing > > functionality. > > Yep. Great future is awaiting PostgreSQL. > > I'm really looking forward to a time when I can find some time to > contribute some actual code. > > Hannu > Hard to argue with this. There are more MAJOR things that I had forgotten. Still, I will say that the things we are working on now are more 'extras', than the stuff we were working on a year ago, which were 'usablility' issues. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
pgsql-hackers by date: