Обсуждение: [HACKERS] Postgres v6.x-v7.0 roadmap

I know that there has been some discussion on this, but thought a
more-or-less explicit roadmap to v7.0 might be helpful. Here are some
thoughts:

1) dump/reload is allowed or required on every formal release (e.g. for
v6.1->v6.2). This will allow incremental improvements to the backend
code without having to put in everything at once.

2) time travel code can be removed during the v6.x releases. It has been
unsupported and de-emphasized (not the word I'm thinking of, but can't
recall what de-x word I want) since v6.0.

3) the most visible improvements and changes from a user's point of view
are in capabilities and user interfaces.

How about targeting an accumulation of capabilities for a v7.0 release?
The accumulated changes might consist of Purifying the code, Vadim's
backend optimizations (fsync improvements, index improvements and
time-travel-removal?), SQL enhancements including subselects, unions,
and rules, and ?? Assuming that we will continue to get incremental
improvements in data types, parsing, etc, I think that subselects must
be high on the list of desirable features which may not magically appear
without a concerted effort.

I would guess that the SQL enhancements will take the most time and
would show up later in the v6.x releases than some of the other items...

Some statement like this on the Web page or attached to the ToDo list
might be helpful.

Comments?

            - Tom

------------------------------

I like this list.  All these items are on the TODO list.  I hate target
them to users until we have someone working on it.  Perhaps a post to
the general list would be helpful.

>
> I know that there has been some discussion on this, but thought a
> more-or-less explicit roadmap to v7.0 might be helpful. Here are some
> thoughts:
>
> 1) dump/reload is allowed or required on every formal release (e.g. for
> v6.1->v6.2). This will allow incremental improvements to the backend
> code without having to put in everything at once.
>
> 2) time travel code can be removed during the v6.x releases. It has been
> unsupported and de-emphasized (not the word I'm thinking of, but can't
> recall what de-x word I want) since v6.0.
>
> 3) the most visible improvements and changes from a user's point of view
> are in capabilities and user interfaces.
>
> How about targeting an accumulation of capabilities for a v7.0 release?
> The accumulated changes might consist of Purifying the code, Vadim's
> backend optimizations (fsync improvements, index improvements and
> time-travel-removal?), SQL enhancements including subselects, unions,
> and rules, and ?? Assuming that we will continue to get incremental
> improvements in data types, parsing, etc, I think that subselects must
> be high on the list of desirable features which may not magically appear
> without a concerted effort.
>
> I would guess that the SQL enhancements will take the most time and
> would show up later in the v6.x releases than some of the other items...
>
> Some statement like this on the Web page or attached to the ToDo list
> might be helpful.
>
> Comments?
>
>             - Tom
>
>


- --
Bruce Momjian
maillist@candle.pha.pa.us

------------------------------

End of hackers-digest V1 #395
*****************************

Bruce Momjian wrote:
> until we have someone working on it.  Perhaps a post to
> the general list would be helpful.

There is/was a place on the Web site for "future directions" or "future
something" which seems like a possible place for something like this as
well as a more general statement.

In the meantime, sign me up for looking at the array indexing problem,
and for adding new date/time routines (e.g. date_trunc(), date_part(),
age(), date_zone()). I'll package up the date/time routines as a
user-installable package for folks to use before v6.2

            - Tom

------------------------------