Re: [INTERFACES] Re: [HACKERS] changes in 6.4

> 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(at)candle(dot)pha(dot)pa(dot)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)