Re: [HACKERS] Patch to mark items as static or not used

On Sat, 2006-07-15 at 00:05 -0400, Tom Lane wrote: > The fundamental problem with find_static is that it hasn't got a clue > about likely future changes, nor about what we think external add-ons > might want We could annotate the source to indicate that some functions are deliberately intended to

Re: [HACKERS] Patch to mark items as static or not used

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The fundamental problem with find_static is that it hasn't got a clue >> about likely future changes, nor about what we think external add-ons >> might want ... > OK, I don't really have a clue either. Is any of it valid? I don't obj

Re: [HACKERS] Patch to mark items as static or not used

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> This time around, please do not remove API functions just because you > >> can't find a reference to them in the core code. I would like to see > >> a posted, discussed patch first. > > > OK, here is my match to

Re: [HACKERS] Patch to mark items as static or not used

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> This time around, please do not remove API functions just because you >> can't find a reference to them in the core code. I would like to see >> a posted, discussed patch first. > OK, here is my match to mark items as static or not us

Re: [HACKERS] src/tools/pginclude considered harmful (was Re: [PATCHES] toast index entries again)

Neil Conway <[EMAIL PROTECTED]> writes: > On Fri, 2006-07-14 at 14:20 -0400, Tom Lane wrote: >> I would like to propose that we revert all the include-related changes >> of the past two days, and that src/tools/pginclude be removed from the >> CVS tree, until such time as it is rewritten to be much

Re: [HACKERS] Forcing wal rotation

Simon Riggs wrote: On Fri, 2006-07-14 at 12:09 -0400, Tom Lane wrote: "Florian G. Pflug" <[EMAIL PROTECTED]> writes: I've now thought about how to fix that without doing that rather crude rsync-pg_xlog-hack. I've read through the code, and learned that wal-segments are expected to have a spec

Re: [HACKERS] contrib promotion?

tsearch2 is functionality that definitely should be in core eventually, but even Oleg still says it's not done. Aside from the documentation issue, it's not clear that we've got a stable API for it. Issues/TODO to move tsearch2 into core (by fast look) * memory management. Dictionaries and tsea

Re: [HACKERS] src/tools/pginclude considered harmful (was Re: [PATCHES]

Martijn van Oosterhout writes: > On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote: >> After some reflection it seems that there is only one case where removal >> of a needed include file would not lead to a compiler error or warning, >> assuming gcc with ordinary -W settings (notably -Wmis

Re: [HACKERS] src/tools/pginclude considered harmful (was Re: [PATCHES]

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> BTW, one of the remaining holes in pgrminclude is that it compiles with >> -fsyntax-only, which apparently causes it to fail to detect some errors >> of significance --- I assume that's how it managed to foul up lmgr.c, >> inet_net_ntop

Re: [HACKERS] src/tools/pginclude considered harmful (was Re:

On Fri, 2006-07-14 at 14:20 -0400, Tom Lane wrote: > I would like to propose that we revert all the include-related changes > of the past two days, and that src/tools/pginclude be removed from the > CVS tree, until such time as it is rewritten to be much smarter about > what it is doing. Rather th

Re: [HACKERS] [PATCHES] c.h is the problem of msvc.

Ooops, I am uncertain at the reason for not knowing __BORLANDC__... It will be sure if __BORLANDC__ has the definition. Thanks. Regards, Hiroshi Saito From: "Tom Lane" "Hiroshi Saito" <[EMAIL PROTECTED]> writes: --- src/include/c.h.orig Sat Jul 15 01:38:59 2006 +++ src/include/c.h Sat Jul

Re: [HACKERS] Three weeks left until feature freeze

Zoltan Boszormenyi <[EMAIL PROTECTED]> writes: > I am working on adding a new column contraint, > namely the GENERATED [ALWAYS | BY DEFAULT ] AS > [ IDENTITY ( sequence_options ) | ( expression )] Doesn't this still have the issue that we're taking over spec-defined syntax to represent behavior th

Re: [HACKERS] src/tools/pginclude considered harmful (was Re: [PATCHES]

On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote: > After some reflection it seems that there is only one case where removal > of a needed include file would not lead to a compiler error or warning, > assuming gcc with ordinary -W settings (notably -Wmissing-prototypes). > That case is exac

Re: [HACKERS] src/tools/pginclude considered harmful (was Re:

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> BTW, one of the remaining holes in pgrminclude is that it compiles with > >> -fsyntax-only, which apparently causes it to fail to detect some errors > >> of significance --- I assume that's how it managed to foul u

Re: [HACKERS] src/tools/pginclude considered harmful (was Re:

Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > On Fri, 2006-07-14 at 14:20 -0400, Tom Lane wrote: > >> I would like to propose that we revert all the include-related changes > >> of the past two days, and that src/tools/pginclude be removed from the > >> CVS tree, until such time as

Re: [HACKERS] src/tools/pginclude considered harmful (was Re:

Andrew Dunstan wrote: > Tom Lane wrote: > > >Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > > > >>I agree with reverting. The tool looks pretty broken anyway, with > >>hardcoded paths and all sorts of stuff quite apart from logic problems. > >> > >> > > > >Well, it's only intended to work

Re: [HACKERS] src/tools/pginclude considered harmful (was Re:

Tom Lane wrote: > Martijn van Oosterhout writes: > > On Fri, Jul 14, 2006 at 04:24:59PM -0400, Tom Lane wrote: > >> After some reflection it seems that there is only one case where removal > >> of a needed include file would not lead to a compiler error or warning, > >> assuming gcc with ordinary

[HACKERS] Patch to mark items as static or not used

Tom Lane wrote: > [EMAIL PROTECTED] (Bruce Momjian) writes: > > Have find_static skip main() functions. > > Uh-oh, don't tell me you are cranking up to run *that* thing again. > > This time around, please do not remove API functions just because you > can't find a reference to them in the core co

Re: [HACKERS] src/tools/pginclude considered harmful (was Re: [PATCHES]

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: I agree with reverting. The tool looks pretty broken anyway, with hardcoded paths and all sorts of stuff quite apart from logic problems. Well, it's only intended to work on Bruce's system, so until someone else takes over the

Re: [HACKERS] Three weeks left until feature freeze

Hi, Bruce Momjian írta: There are roughly three weeks left until the feature freeze on August 1. If people are working on items, they should be announced before August 1, and the patches submitted by August 1. If the patch is large, it should be discussed now and an intermediate patch posted to

Re: [HACKERS] src/tools/pginclude considered harmful (was Re: [PATCHES]

Andrew Dunstan <[EMAIL PROTECTED]> writes: > I agree with reverting. The tool looks pretty broken anyway, with > hardcoded paths and all sorts of stuff quite apart from logic problems. Well, it's only intended to work on Bruce's system, so until someone else takes over the position of chief grunt

Re: [HACKERS] [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

Peter Eisentraut <[EMAIL PROTECTED]> writes: > The merge sort is here: > http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/msort.c?rev=1.21&content-type=text/x-cvsweb-markup&cvsroot=glibc > It uses alloca, so we're good here. Uh ... but it also uses malloc, and potentially a honkin' big mallo

Re: [HACKERS] [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

Tom Lane wrote: > > Doesn't look like it's allocating any nonlocal memory: > > > > http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/qsort.c?rev=1. > >12&content-type=text/x-cvsweb-markup&cvsroot=glibc > > But this file defines _quicksort() not qsort(). I was under the > impression that the lat

Re: [HACKERS] src/tools/pginclude considered harmful (was Re: [PATCHES]

Tom Lane wrote: In combination with the amount of time wasted over the past two days, it is now perfectly clear that the existing pginclude tools are not NEARLY good enough to detect what they are breaking. I would like to propose that we revert all the include-related changes of the past two d

Re: [HACKERS] [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> We might have to just tolerate this, but if it occurs on a lot of >> platforms I'd have second thoughts about applying the patch. Anyone >> familiar with the internals of glibc's qsort, in particular? > Doesn't look like it's alloc

Re: [HACKERS] [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

Tom Lane wrote: > We might have to just tolerate this, but if it occurs on a lot of > platforms I'd have second thoughts about applying the patch. Anyone > familiar with the internals of glibc's qsort, in particular? Doesn't look like it's allocating any nonlocal memory: http://sourceware.org/cg

Re: [HACKERS] contrib promotion?

Peter Eisentraut wrote: Quite apart from anything else, it's important that we do get better docco on these modules. I'm willing to help with DocBook options. What do you have in mind? Well, if we could make provision for sucking in a chapter per contrib module if it exists that w

Re: [HACKERS] [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

"Charles Duffy" <[EMAIL PROTECTED]> writes: > [ CHECK_FOR_INTERRUPTS inside qsort comparison routine ] It occurs to me that there's a nonzero risk of problems here, because if the interrupt occurs qsort() will lose control. I'm wondering whether there are any implementations of qsort() that alloc

[HACKERS] src/tools/pginclude considered harmful (was Re: [PATCHES] toast index entries again)

Kris Jurka <[EMAIL PROTECTED]> writes: > The inclusion of access/tuptoaster.h in access/common/indextuple.c brought > in the define of TOAST_INDEX_HACK which compresses large index entries. > When this was removed the entries were no longer compressed which caused > btree_gist to fail. This is

Re: [HACKERS] contrib promotion?

Greg Sabino Mullane wrote: > Doesn't our inclusion of md5() pretty much blow that argument away? (Just asking). >>> I don't think so because md5 is just a one way hash function. There >>> is no method to decrypt anything :). > > Actually, I've had to install pgcrypto on more than one oc

Re: [HACKERS] contrib promotion?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> Doesn't our inclusion of md5() pretty much blow that argument away? >> (Just asking). > > I don't think so because md5 is just a one way hash function. There > is no method to decrypt anything :). Actually, I've had to install pgcrypto on more th

Re: [HACKERS] [PATCHES] [patch 0/9] annual pgcrypto update

I wrote: > Applied, thanks. What I now see is that pgp-pubkey-decrypt passes on > a 32-bit machine but dumps core on a 64-bit machine, with SIGSEGV here: Addendum: seems it only fails without openssl. regards, tom lane ---(end of broadcast)---

Re: [HACKERS] [PATCHES] [patch 0/9] annual pgcrypto update

"Marko Kreen" <[EMAIL PROTECTED]> writes: > On 7/13/06, Neil Conway <[EMAIL PROTECTED]> wrote: >> Marko, can you take a look at what is causing this regression test >> failure? The failing machine is kudu: > Seems you have skipped the CAST5 patch. Could you recheck? Applied, thanks. What I now

Re: [HACKERS] [PATCHES] c.h is the problem of msvc.

"Hiroshi Saito" <[EMAIL PROTECTED]> writes: > --- src/include/c.h.orig Sat Jul 15 01:38:59 2006 > +++ src/include/c.h Sat Jul 15 01:40:04 2006 > @@ -60,7 +60,9 @@ > #if defined(_MSC_VER) || defined(__BORLANDC__) > #define WIN32_ONLY_COMPILER > #define errcode __vc_errcode > +#if (_MS

Re: [HACKERS] [PATCHES] build with different options than Bruce

Kris Jurka <[EMAIL PROTECTED]> writes: > When building with --enable-cassert, without --enable-thread-safety, or > when the OS supports USE_WIDE_UPPER_LOWER we need some more include files. Done, thanks. regards, tom lane ---(end of broadcast)

Re: [HACKERS] contrib promotion?

Andrew Dunstan wrote: > >I don't see a strong need for moving pgcrypto into core, and there's > > at least one argument against it: if someone needs a crypto-free > > version of postgres for use someplace with benighted laws, they > > would be screwed. > > Could that be handled with a configure opt

Re: [HACKERS] contrib promotion?

On Jul 14, 2006, at 12:32 PM, Joshua D. Drake wrote: Doesn't our inclusion of md5() pretty much blow that argument away? (Just asking). I don't think so because md5 is just a one way hash function. There is no method to decrypt anything :). John DeSoi, Ph.D. http://pgedit.com/ Power T

Re: [HACKERS] Forcing wal rotation

On Fri, 2006-07-14 at 12:09 -0400, Tom Lane wrote: > "Florian G. Pflug" <[EMAIL PROTECTED]> writes: > > I've now thought about how to fix that without doing that rather crude > > rsync-pg_xlog-hack. > > I've read through the code, and learned that wal-segments are expected to > > have a specific

Re: [HACKERS] contrib promotion?

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I don't see a strong need for moving pgcrypto into core, and there's at >> least one argument against it: if someone needs a crypto-free version of >> postgres for use someplace with benighted laws, they would be screwed. > Doesn't

Re: [HACKERS] contrib promotion?

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: There has been action to clean up and remove some contrib modules, and this is good. I would like to suggest that we should try to move one or two the other way, namely right into the core proper, on the ground that they have widesprea

Re: [HACKERS] contrib promotion?

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: There has been action to clean up and remove some contrib modules, and this is good. I would like to suggest that we should try to move one or two the other way, namely right into the core proper, on the ground that they have wides

Re: [HACKERS] Forcing wal rotation

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Florian G. Pflug > Sent: 14 July 2006 16:37 > To: Postgresql-General > Cc: A.M. > Subject: Re: [HACKERS] Forcing wal rotation > > > How about an SQL-level function that calls the wal scripts? >

Re: [HACKERS] Forcing wal rotation

"Florian G. Pflug" <[EMAIL PROTECTED]> writes: > I've now thought about how to fix that without doing that rather crude > rsync-pg_xlog-hack. > I've read through the code, and learned that wal-segments are expected to > have a specific size - > thus rotating them "early" is not that easy. Simon

Re: [HACKERS] [COMMITTERS] pgsql: Have find_static skip main() functions.

[EMAIL PROTECTED] (Bruce Momjian) writes: > Have find_static skip main() functions. Uh-oh, don't tell me you are cranking up to run *that* thing again. This time around, please do not remove API functions just because you can't find a reference to them in the core code. I would like to see a pos

Re: [HACKERS] contrib promotion?

Andrew Dunstan <[EMAIL PROTECTED]> writes: > There has been action to clean up and remove some contrib modules, and > this is good. I would like to suggest that we should try to move one or > two the other way, namely right into the core proper, on the ground that > they have widespread applicab

Re: [HACKERS] Forcing wal rotation

Martijn van Oosterhout wrote: On Fri, Jul 14, 2006 at 05:36:58PM +0200, Florian G. Pflug wrote: That was the idea - providing pg_rotate_wal(), which would guarantee that the wal is rotatted at least once if called. Thinking further about this, for a first prove of concept, I'd be enough to write

Re: [HACKERS] Forcing wal rotation

On Fri, Jul 14, 2006 at 05:36:58PM +0200, Florian G. Pflug wrote: > That was the idea - providing pg_rotate_wal(), which would guarantee that > the wal is rotatted at least once if called. Thinking further about this, > for a first prove of concept, I'd be enough to write a C function > pg_current_

Re: [HACKERS] Forcing wal rotation

A.M. wrote: On Fri, July 14, 2006 11:20 am, Florian G. Pflug wrote: Hi For my warm-standby-cluster I'm now saving the currently used wal using rsync, to avoid loosing data from a few hours (or days) ago, when there is little traffic, and thus the wal isn't rotated. For online backups, the prob

Re: [HACKERS] [PATCHES] [patch 0/9] annual pgcrypto update

On 7/13/06, Neil Conway <[EMAIL PROTECTED]> wrote: Marko, can you take a look at what is causing this regression test failure? The failing machine is kudu: Seems you have skipped the CAST5 patch. Could you recheck? -- marko ---(end of broadcast)---

[HACKERS] Forcing wal rotation

Hi For my warm-standby-cluster I'm now saving the currently used wal using rsync, to avoid loosing data from a few hours (or days) ago, when there is little traffic, and thus the wal isn't rotated. For online backups, the problem is even worse, because a backup might me unuseable even hours aft

Re: [HACKERS] ShmemAlloc() alignment patch

Bruce Momjian <[EMAIL PROTECTED]> writes: >>> How can ShmemBase not be aligned? Surely it's page-aligned? > Should we add an assert? No, because even if it's not page-aligned, there's no correctness issue here. (Besides, how would you know what the page size is on any given platform?)

Re: [HACKERS] ShmemAlloc() alignment patch

Tom Lane wrote: > Martijn van Oosterhout writes: > > On Fri, Jul 14, 2006 at 02:50:31PM +0800, Qingqing Zhou wrote: > >> Notice that though newStart is ALIGNOF_BUFFER, ShmemBase is not. Thus the > >> newSpace is not aligned as we disired. > > > How can ShmemBase not be aligned? Surely it's page-a

Re: [HACKERS] ShmemAlloc() alignment patch

Martijn van Oosterhout writes: > On Fri, Jul 14, 2006 at 02:50:31PM +0800, Qingqing Zhou wrote: >> Notice that though newStart is ALIGNOF_BUFFER, ShmemBase is not. Thus the >> newSpace is not aligned as we disired. > How can ShmemBase not be aligned? Surely it's page-aligned? That's certainly wh

Re: [HACKERS] [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()

"Charles Duffy" <[EMAIL PROTECTED]> writes: > On 7/12/06, Qingqing Zhou <[EMAIL PROTECTED]> wrote: >> the problem here is that 29247 doesn't look like a big number so I can't see >> why your patch solved the problem, unless the qsort_comparetup() function of >> the data type eats too many circles o

Re: [HACKERS] monolithic distro

Since I appreantly like monologs .. MySQL also has other features that are not available via pgfoundery like being able to determine the default charset on the database, table and column level, as well as COLLATE support to determine the sort order at runtime. SHOW ALL; ? Anyways what I

Re: [HACKERS] xlogdump enhancements

On 7/14/06, Jonah H. Harris <[EMAIL PROTECTED]> wrote: On 7/14/06, Martijn van Oosterhout wrote:> If you really want to tackle this the hard way, find some other program> that does it. Here one written in Perl that can decode most tuples, but > not all. It fails because it doesn

[HACKERS] contrib promotion?

There has been action to clean up and remove some contrib modules, and this is good. I would like to suggest that we should try to move one or two the other way, namely right into the core proper, on the ground that they have widespread applicability and should have maximum visibility. I'm ta

Re: [HACKERS] 8.2 features?

Bernd Helmle wrote: --On Freitag, Juli 14, 2006 01:23:11 +0200 Peter Eisentraut <[EMAIL PROTECTED]> wrote: . multiple values clauses for INSERT Susanne Ebrecht <[EMAIL PROTECTED]> was last heard to work on it. Updates, Susanne? I've talked to Susanne today and she's just back from h

Re: [HACKERS] Fwd: Three weeks left until feature freeze

Peter Eisentraut wrote: Joshua D. Drake wrote: For example there is NOT an PostgreSQL 8.1 for Ubuntu Breezy. http://packages.ubuntu.com/breezy-backports/misc/ Thanks Peter :), I knew about backports but didn't know what was in there. But what about when 8.2 comes out? Doubtful that they wil

Re: [HACKERS] [PATCHES] include compile problems

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Patch applied. Thanks. > > I suspect the point was that limits.h is needed *instead of* math.h, > not *in addition to*. How many of those headers had math.h before? The issue was that an include file included another include file t

Re: [HACKERS] 8.2 features?

--On Freitag, Juli 14, 2006 01:23:11 +0200 Peter Eisentraut <[EMAIL PROTECTED]> wrote: . multiple values clauses for INSERT Susanne Ebrecht <[EMAIL PROTECTED]> was last heard to work on it. Updates, Susanne? I've talked to Susanne today and she's just back from hospital and not availab

Re: [HACKERS] xlogdump enhancements

On 7/14/06, Martijn van Oosterhout wrote: If you really want to tackle this the hard way, find some other program that does it. Here one written in Perl that can decode most tuples, but not all. It fails because it doesn't recognise all the types. Yep Diogo, Martijn is correct. You have to re

Re: [HACKERS] xlogdump enhancements

On Fri, Jul 14, 2006 at 10:43:15AM -0300, Diogo Biazus wrote: > I'm working on Tom's xlogdump tool to add some functionality. > IMHO some useful improvements would be and an idea of implementation: Neato. Looks like good stuff there. > - Extract the exact SQL statement in cases of xlog generated

Re: [HACKERS] pgsql-patches considered harmful

On Fri, 14 Jul 2006, Hannu Krosing wrote: Ühel kenal päeval, K, 2006-07-12 kell 23:04, kirjutas Marc G. Fournier: On Wed, 12 Jul 2006, Magnus Hagander wrote: There are list servers out there capable of simply ripping any attachments to a message (possibly over a certain size) and stick it on

[HACKERS] xlogdump enhancements

I'm working on Tom's xlogdump tool to add some functionality.IMHO some useful improvements would be and an idea of implementation:- have an options to output only the transactions with their status and some aggregate data (transaction size). When the user pass a -t parameter, instead of printing ec

Re: [HACKERS] monolithic distro

Andrew Dunstan wrote: The topic here is NOT what features are missing from postgres. Of course it is ;-) Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] monolithic distro

Lukas Smith wrote: Since I appreantly like monologs .. MySQL also has other features that are not available via pgfoundery like being able to determine the default charset on the database, table and column level, as well as COLLATE support to determine the sort order at runtime. Anyways wha

Re: [HACKERS] monolithic distro

Lukas Smith wrote: Lukas Smith wrote: Peter Eisentraut wrote: Lukas Kahwe Smith wrote: whereas PostgreSQL is continuously complaing that MySQL is inferior yet way more popular. Maybe MySQL's popularity is not even PostgreSQL's goal, but I am sure a bit more would be welcome. Does MySQL have

Re: [HACKERS] Three weeks left until feature freeze

Ühel kenal päeval, K, 2006-07-12 kell 17:48, kirjutas Thomas Hallgren: > Andrew Dunstan wrote: > > There is in effect no API at all, other than what is available to all > > backend modules. If someone wants to create an API which will be both > > sufficiently stable and sufficiently complete to m

Re: [HACKERS] pgsql-patches considered harmful

Ühel kenal päeval, K, 2006-07-12 kell 23:04, kirjutas Marc G. Fournier: > On Wed, 12 Jul 2006, Magnus Hagander wrote: > > > There are list servers out there capable of simply ripping any > > attachments to a message (possibly over a certain size) and stick it on > > a website, replacing it with

Re: [HACKERS] ShmemAlloc() alignment patch

On Fri, Jul 14, 2006 at 02:50:31PM +0800, Qingqing Zhou wrote: > In ShmemAlloc() we have: > > newStart = BUFFERALIGN(newStart); > newSpace = (void *) (ShmemBase + newStart); > return newSpace; > > Notice that though newStart is ALIGNOF_BUFFER, ShmemBase is not. Thus the > newSpace is not al

Re: [HACKERS] Fwd: Three weeks left until feature freeze

Joshua D. Drake wrote: > For example there is NOT an PostgreSQL 8.1 for Ubuntu Breezy. http://packages.ubuntu.com/breezy-backports/misc/ -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below