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