Hi everyone,

I'm just interested in what everyone's personal plans for 7.5 
development are?

Shridar, Gavin and myself are trying to get the tablespaces stuff off 
the ground.  Hopefully we'll have a CVS set up for us to work in at some 
point (we didn't think getting a branch and commit privs was likely). 
Changing all our $Id$ tags to $Postgres$ would make a separate CVS a lot 
easier, hint hint :)

What's everyone else wanting to work on?

Chris



Thu, 27 Nov 2003 10:27:22 +0800
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
7.5 Plans
On Thu, Nov 27, 2003 at 10:27:22AM +0800, Christopher Kings-Lynne wrote:

> What's everyone else wanting to work on?

I want to get the nested transaction patch thingie sorted out.
I feel it's not that far away.  After that, maybe

- try using a pg_shareddepend shared catalog to check user dependencies

- get VACUUM FULL to REINDEX instead of munging individual index tuples

- try to come out with something to enable aggregates optimization by
  using an aggregate-specific function to check the plan tree

Anyway, if I get nested xacts in 7.5 I'll be more than happy ...


(I will probably be doing lots of translation work too, or maybe enable
someone else to do it ...)

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Dios hizo a Adï¿½n, pero fue Eva quien lo hizo hombre.

Thu, 27 Nov 2003 00:10:59 -0300
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: 7.5 Plans
On Thu, 27 Nov 2003, Christopher Kings-Lynne wrote:

> Changing all our $Id$ tags to $Postgres$ would make a separate CVS a lot
> easier, hint hint :)

Why?  From the info pages:

`$Header$'
     A standard header containing the full pathname of the RCS file,
     the revision number, the date (UTC), the author, the state, and
     the locker (if locked).  Files will normally never be locked when
     you use CVS.

`$Id$'
     Same as `$Header$', except that the RCS filename is without a path.

So, what does changing it to $PostgreSQL$ do?  Or am I reading the wrong
part of the manual?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Wed, 26 Nov 2003 23:30:23 -0400 (AST)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: 7.5 Plans
> So, what does changing it to $PostgreSQL$ do?  Or am I reading the wrong
> part of the manual?

After applying the patch in -patches to CVSROOT and running the update
script...

It will allow Chris and other to import the PostgreSQL source into their
own CVS tree without having do to a ton of diff editing to reimport /
export changes between the primary tree and their development tree.

Forking the main PostgreSQL tree 30 times for the various groups to do
development isn't appropriate nor necessary when we can just change the
ID that PostgreSQL uses to something different.

The BSDs wen't through similar measures to ensure they could maintain
multiple CVS sources without diff / patch going nuts.


Wed, 26 Nov 2003 23:05:51 -0500
Rod Taylor <pg@rbt.ca>
Re: 7.5 Plans
On Wed, 26 Nov 2003, Rod Taylor wrote:

> > So, what does changing it to $PostgreSQL$ do?  Or am I reading the wrong
> > part of the manual?
>
> After applying the patch in -patches to CVSROOT and running the update
> script...
>
> It will allow Chris and other to import the PostgreSQL source into their
> own CVS tree without having do to a ton of diff editing to reimport /
> export changes between the primary tree and their development tree.

'k, but why can't that be accomplished with $Id$?

Are there any caveats to the change?  Ie. if Tom has a checkout and this
change is made, will he have problems committing?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Thu, 27 Nov 2003 00:32:44 -0400 (AST)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: 7.5 Plans
Rod Taylor <pg@rbt.ca> writes:
>> So, what does changing it to $PostgreSQL$ do?  Or am I reading the wrong
>> part of the manual?

> The BSDs wen't through similar measures to ensure they could maintain
> multiple CVS sources without diff / patch going nuts.

Yeah, I have gotten similar requests from Red Hat's internal development
group.  $PostgreSQL$ doesn't do anything for *us* ... but it makes life
easier for other people trying to import PG sources into their own CVS
trees.  In light of the Grand Scheme for World Domination, that seems
like a worthwhile improvement to me ;-)

			regards, tom lane

Thu, 27 Nov 2003 00:11:51 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.5 Plans 
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> 'k, but why can't that be accomplished with $Id$?

$Id$ isn't much better than $Header$ --- the point is to avoid keywords
that downstream people's CVS repositories will want to replace.

> Are there any caveats to the change?  Ie. if Tom has a checkout and this
> change is made, will he have problems committing?

Making the change will mean a big "cvs update" pass for everyone, but
no worse than what happens every time Bruce hits the copyright dates,
for example.  It's a one-line change in every file AFAICS.

I'd recommend giving committers a day or two's notice of the edit, same
as Bruce typically does for pgindent runs, but there's no reason to
consider it any worse than that.

			regards, tom lane

Thu, 27 Nov 2003 00:23:40 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.5 Plans 
On Wed, 2003-11-26 at 23:32, Marc G. Fournier wrote:
> On Wed, 26 Nov 2003, Rod Taylor wrote:
> 
> > > So, what does changing it to $PostgreSQL$ do?  Or am I reading the wrong
> > > part of the manual?
> >
> > After applying the patch in -patches to CVSROOT and running the update
> > script...
> >
> > It will allow Chris and other to import the PostgreSQL source into their
> > own CVS tree without having do to a ton of diff editing to reimport /
> > export changes between the primary tree and their development tree.
> 
> 'k, but why can't that be accomplished with $Id$?

When you import the files into the other CVS system the version and file
information $Id$ represents will be replaced by the other system. So,
when you diff the original (primary repository) EVERY file will show
$Id$ has changed.

> Are there any caveats to the change?  Ie. if Tom has a checkout and this
> change is made, will he have problems committing?

$VARIABLE$ is used for informational purposes only AFAIK. There would be
no change that I know of.

At work I use $InQuent$, FreeBSD of course uses $FreeBSD$ of which other
BSDs follow suite $NetBSD$ and $OpenBSD$. I've not heard of any issues
with 3rd party CVS clients and any of those repositories in this regard.


Thu, 27 Nov 2003 00:36:27 -0500
Rod Taylor <pg@rbt.ca>
Re: 7.5 Plans
Christopher Kings-Lynne wrote:

> Hi everyone,
> 
> I'm just interested in what everyone's personal plans for 7.5 
> development are?
> 
> Shridar, Gavin and myself are trying to get the tablespaces stuff off 
> the ground.  Hopefully we'll have a CVS set up for us to work in at some 
> point (we didn't think getting a branch and commit privs was likely). 
> Changing all our $Id$ tags to $Postgres$ would make a separate CVS a lot 
> easier, hint hint :)
> 
> What's everyone else wanting to work on?

By the time tablespaces CVS goes live, I plan to study postgresql buffer 
management and push mmap. (See other thread). Hopefully my home internet 
connection will be up soon so that I can work on weekends.

  Shridhar


Thu, 27 Nov 2003 11:47:45 +0530
Shridhar Daithankar <shridhar_daithankar@myrealbox.com>
Re: 7.5 Plans
Rod Taylor <pg@rbt.ca> writes:
> On Wed, 2003-11-26 at 23:32, Marc G. Fournier wrote:
>> 'k, but why can't that be accomplished with $Id$?

> When you import the files into the other CVS system the version and file
> information $Id$ represents will be replaced by the other system. So,
> when you diff the original (primary repository) EVERY file will show
> $Id$ has changed.

Right.  I can write a long sob story about the pain this has caused
within Red Hat ... likely other people can say the same ... but the
executive summary is:

1. You can't easily generate a clean diff of your local version against
the original imported from postgresql.org.  The changes you actually
made get buried in a mass of useless $Foo$ diff lines.  Stripping those
out is possible in theory but painful.

2. You can't easily see which postgresql.org original version your local
copy was actually derived from, because guess what, your local CVS
server is going out of its way to hide the evidence.

These effects not only cause pain for the downstream users, but
interfere with them contributing their changes back upstream (by making
it many orders of magnitude harder to generate a clean diff to send us).
So we should fix it.

			regards, tom lane

Thu, 27 Nov 2003 01:18:18 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.5 Plans 
Tom Lane wrote:
> 1. You can't easily generate a clean diff of your local version against
> the original imported from postgresql.org.  The changes you actually
> made get buried in a mass of useless $Foo$ diff lines.  Stripping those
> out is possible in theory but painful.

Is that the reason linux does not use CVS? I thought so at least.

  Shridhar


Thu, 27 Nov 2003 12:20:57 +0530
Shridhar Daithankar <shridhar_daithankar@myrealbox.com>
Re: 7.5 Plans
Shridhar Daithankar <shridhar_daithankar@myrealbox.com> writes:

> Tom Lane wrote:
>> 1. You can't easily generate a clean diff of your local version against
>> the original imported from postgresql.org.  The changes you actually
>> made get buried in a mass of useless $Foo$ diff lines.  Stripping those
>> out is possible in theory but painful.
>
> Is that the reason linux does not use CVS? I thought so at least.

It's probably one of a very large number of reasons.  For a project on
the scale of Linux, CVS basically sucks--it's too centralized anad has
no concept of "changesets".

-Doug

Thu, 27 Nov 2003 08:45:21 -0500
Doug McNaught <doug@mcnaught.org>
Re: 7.5 Plans
Christopher Kings-Lynne writes:

> I'm just interested in what everyone's personal plans for 7.5
> development are?

Here is a pretty good hit list:

http://developer.postgresql.org/docs/postgres/unsupported-features-sql99.html

There are still some low-hanging fruit and some
below-the-cloudy-sky-hanging fruit in there, for instance

Finishing ECPG's dynamic SQL support
Column privileges
Updatable views
Distinct data types
Basic array support
BLOB and CLOB types
Chained transactions
Basic roles

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 27 Nov 2003 18:28:16 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: 7.5 Plans
Alvaro Herrera writes:

> (I will probably be doing lots of translation work too, or maybe enable
> someone else to do it ...)

I think in 7.5 we'll be able to get everything fully translat{ed|able}.
We already have initdb, and we'll do ecpg, pg_ctl, and decide the fate of
initlocation and ipcclean.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 27 Nov 2003 18:30:54 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: 7.5 Plans
On Thu, Nov 27, 2003 at 06:30:54PM +0100, Peter Eisentraut wrote:
> Alvaro Herrera writes:
> 
> > (I will probably be doing lots of translation work too, or maybe enable
> > someone else to do it ...)
> 
> I think in 7.5 we'll be able to get everything fully translat{ed|able}.
> We already have initdb, and we'll do ecpg, pg_ctl, and decide the fate of
> initlocation and ipcclean.

You are forgetting the PLs ...

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Use it up, wear it out, make it do, or do without"

Thu, 27 Nov 2003 15:12:15 -0300
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: 7.5 Plans
Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
>>I'm just interested in what everyone's personal plans for 7.5
>>development are?

> There are still some low-hanging fruit and some
> below-the-cloudy-sky-hanging fruit in there, for instance

[...snip...]

> Basic array support
   ^^^^^^^^^^^^^^^^^^^
I'm planning to keep plugging away at this one, particularly the items 
pointed out by Peter last July.

I'm also hoping to work on aggregates that accept two arguments (binary 
set functions), e.g. REGR_*, and possibly window frame aggregates (both 
ala SQL2003 section 4.15.4 and 10.9). Both could be classified as OLAP 
functionality.

Possibly more stuff.

Joe


Thu, 27 Nov 2003 21:38:44 -0800
Joe Conway <mail@joeconway.com>
Re: 7.5 Plans