7.1 items

Bruce Momjian wrote:

Am I correct that we are targeting all these for 7.1?

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign

There have been talks about redesigning fmgr and pl-function
interface as well ;)

Oops, yes:

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign
function manager redesign

What year to we want to release 7.1? :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian writes:

Oops, yes:

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign
function manager redesign

What year to we want to release 7.1? :-)

ISTM that any one of these features could lead to a release of its own
right. Considering that at least four of these five were planned for 7.0
we perhaps shouldn't be overly enthusiastic (although ambitious plans
never hurt).

FWIW, my own plans for 7.1 revolve around ACL enhancements and build
system clean up.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

On Wed, 5 Apr 2000, Bruce Momjian wrote:

Bruce Momjian wrote:

Am I correct that we are targeting all these for 7.1?

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign

There have been talks about redesigning fmgr and pl-function
interface as well ;)

Oops, yes:

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign
function manager redesign

What year to we want to release 7.1? :-)

Based on this last one ... Jan/Feb 1st, 2001 would be nice? :)

On Thu, 6 Apr 2000, Peter Eisentraut wrote:

Bruce Momjian writes:

Oops, yes:

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign
function manager redesign

What year to we want to release 7.1? :-)

If all will right (and major developers will agree) I plan PREPARE/EXECUTE
commands and changes in SPI background for plan saving (query cache).

FWIW, my own plans for 7.1 revolve around ACL enhancements and build
system clean up.

And if will implemented new ACL, I plan CREATE PROFILE feature (like Oracle)
for better user control (connection elapsed time, time period for connection,
default ACL mask ..ect.) .

Karel

Am I correct that we are targeting all these for 7.1?
outer joins
query tree redesign

We are pretty much agreed that outer joins will be much easier with a
query tree redesign. But if anyone wants to try shoehorning at least a
simple example of outer joins into the current design they are welcome
to try.

I'm also planning on working on the multi-language support, using the
SQL92 NATIONAL CHARACTER/CHARACTER SET/COLLATION features.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

Karel Zak <zakkr@zf.jcu.cz> writes:

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign
function manager redesign

What year to we want to release 7.1? :-)

If all will right (and major developers will agree) I plan PREPARE/EXECUTE
commands and changes in SPI background for plan saving (query cache).

Given that there is going to be a querytree redesign for 7.1, I'd
suggest holding off on prepared plans until 7.2. Otherwise it's
going to be a mess.

The good thing about the above list is that we have four essentially
independent major projects. (I think outer joins are a portion of the
querytree work, not a separate item.) So work on them can proceed in
parallel. And, if it gets to be September-ish and only two or three
are done, we can make a 7.1 release and still feel pretty good about
having some nice stuff.

This does bring up a suggestion that Jan has made in the past. Perhaps
it would be a good idea if we create a separate CVS branch for each of
these major projects, so that people could work on that project
independently of the others. When a project is done, we merge it back
into the main branch. Then it's no problem if one of the projects is
broken temporarily, or not ready to go when we want to release 7.1.

OTOH, managing separate CVS branches might be a real pain in the neck,
especially for developers who need to deal with more than one project.
I've never done it so I don't have a feeling for what it would take.
But the Mozilla people do this sort of thing all the time, so it can't
be that bad.

regards, tom lane

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign
function manager redesign

What year to we want to release 7.1? :-)

If all will right (and major developers will agree) I plan PREPARE/EXECUTE
commands and changes in SPI background for plan saving (query cache).

Given that there is going to be a querytree redesign for 7.1, I'd
suggest holding off on prepared plans until 7.2. Otherwise it's
going to be a mess.

Any chance for dirty read? Waiting for transaction end on inserts with
duplicates on unique keys in transactions can be a lot of fun.

But we have committed read with no block. Why would you want dirty
read. Chapter 10 of my book is about transactions and locking. Of
course, I may be missing something here.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Thu, 6 Apr 2000, Tom Lane wrote:

Karel Zak <zakkr@zf.jcu.cz> writes:

If all will right (and major developers will agree) I plan PREPARE/EXECUTE
commands and changes in SPI background for plan saving (query cache).

This does bring up a suggestion that Jan has made in the past. Perhaps
it would be a good idea if we create a separate CVS branch for each of
these major projects, so that people could work on that project
independently of the others. When a project is done, we merge it back
into the main branch. Then it's no problem if one of the projects is
broken temporarily, or not ready to go when we want to release 7.1.

I agree.

Karel

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign
function manager redesign

What year to we want to release 7.1? :-)

If all will right (and major developers will agree) I plan PREPARE/EXECUTE
commands and changes in SPI background for plan saving (query cache).

Given that there is going to be a querytree redesign for 7.1, I'd
suggest holding off on prepared plans until 7.2. Otherwise it's
going to be a mess.

Any chance for dirty read? Waiting for transaction end on inserts with
duplicates on unique keys in transactions can be a lot of fun.

Regards
Theo

On Thu, 6 Apr 2000, Tom Lane wrote:

Karel Zak <zakkr@zf.jcu.cz> writes:

WAL/write ahead log
TOAST/long tuples
outer joins
query tree redesign
function manager redesign

What year to we want to release 7.1? :-)

If all will right (and major developers will agree) I plan PREPARE/EXECUTE
commands and changes in SPI background for plan saving (query cache).

Given that there is going to be a querytree redesign for 7.1, I'd
suggest holding off on prepared plans until 7.2. Otherwise it's
going to be a mess.

The good thing about the above list is that we have four essentially
independent major projects. (I think outer joins are a portion of the
querytree work, not a separate item.) So work on them can proceed in
parallel. And, if it gets to be September-ish and only two or three
are done, we can make a 7.1 release and still feel pretty good about
having some nice stuff.

This does bring up a suggestion that Jan has made in the past. Perhaps
it would be a good idea if we create a separate CVS branch for each of
these major projects, so that people could work on that project
independently of the others. When a project is done, we merge it back
into the main branch. Then it's no problem if one of the projects is
broken temporarily, or not ready to go when we want to release 7.1.

OTOH, managing separate CVS branches might be a real pain in the neck,
especially for developers who need to deal with more than one project.
I've never done it so I don't have a feeling for what it would take.
But the Mozilla people do this sort of thing all the time, so it can't
be that bad.

I've only ever seen it done for the kernel of FreeBSD, and very very
rarely at that ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org