Thread: 7.5 Plans
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
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 plantree 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.
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), theauthor, 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
> 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.
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
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
"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
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.
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
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
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
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
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
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
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"
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