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