On Mon, Aug 25, 2014 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
OK, I will move in the direction of removing 8.3 support and use a
single query to pull schema information. I was hesistant to remove 8.3
support as I know we have kept pg_dump support
On Wed, Aug 27, 2014 at 09:54:11AM -0400, Robert Haas wrote:
Having said that, there are obviously advantages for our users if we
don't get too crazy about requiring that. I've used products in the
past where to get from version 3 to version 11 you have to upgrade
from 3 to 5, then 5 to 7,
On Wed, Aug 27, 2014 at 10:13 AM, Bruce Momjian br...@momjian.us wrote:
On Wed, Aug 27, 2014 at 09:54:11AM -0400, Robert Haas wrote:
Having said that, there are obviously advantages for our users if we
don't get too crazy about requiring that. I've used products in the
past where to get from
--On 21. August 2014 22:08:58 +0200 Magnus Hagander mag...@hagander.net
wrote:
I vote for discarding 8.3 support in pg_upgrade. There are already
enough limitations on pg_upgrade from pre-8.4 to make it of questionable
value; if it's going to create problems like this, it's time to cut the
Bernd Helmle maili...@oopsware.de wrote:
Magnus Hagander mag...@hagander.net wrote:
I vote for discarding 8.3 support in pg_upgrade. There are already
enough limitations on pg_upgrade from pre-8.4 to make it of questionable
value; if it's going to create problems like this, it's time to cut
On Mon, Aug 25, 2014 at 06:34:12AM -0700, Kevin Grittner wrote:
Bernd Helmle maili...@oopsware.de wrote:
Magnus Hagander mag...@hagander.net wrote:
I vote for discarding 8.3 support in pg_upgrade. There are already
enough limitations on pg_upgrade from pre-8.4 to make it of questionable
Bruce Momjian br...@momjian.us writes:
OK, I will move in the direction of removing 8.3 support and use a
single query to pull schema information. I was hesistant to remove 8.3
support as I know we have kept pg_dump support all the way back to 7.0,
but it seems pg_upgrade need not have the
On Mon, Aug 25, 2014 at 03:04:52PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
OK, I will move in the direction of removing 8.3 support and use a
single query to pull schema information. I was hesistant to remove 8.3
support as I know we have kept pg_dump support all the
On Mon, Aug 25, 2014 at 02:15:18PM -0400, Bruce Momjian wrote:
On Mon, Aug 25, 2014 at 06:34:12AM -0700, Kevin Grittner wrote:
Bernd Helmle maili...@oopsware.de wrote:
Magnus Hagander mag...@hagander.net wrote:
I vote for discarding 8.3 support in pg_upgrade. There are already
On Mon, Aug 25, 2014 at 06:34:38PM -0400, Bruce Momjian wrote:
OK, I will move in the direction of removing 8.3 support and use a
single query to pull schema information. I was hesistant to remove 8.3
support as I know we have kept pg_dump support all the way back to 7.0,
but it seems
Bruce Momjian wrote
I had to make an exception for temporary tables because pg_upgrade uses
temporary tables to collect schema information. I tried writing the
query to use CTEs (second patch), but I would then have to have one
query for 8.3, which doesn't support CTEs, and another for 8.4+,
On Thu, Aug 21, 2014 at 11:43:42AM -0700, David G Johnston wrote:
Bruce Momjian wrote
I had to make an exception for temporary tables because pg_upgrade uses
temporary tables to collect schema information. I tried writing the
query to use CTEs (second patch), but I would then have to have
Bruce Momjian br...@momjian.us writes:
Specifically, the first attached patch causes pg_upgrade_support
functions to throw errors when called by a backend that is not in binary
upgrade mode. (This seems like a good safety measure.)
Agreed about that part.
Second, and
more importantly, the
On Thu, Aug 21, 2014 at 10:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
I tried writing the
query to use CTEs (second patch), but I would then have to have one
query for 8.3, which doesn't support CTEs, and another for 8.4+, plus
the CTE query was more
14 matches
Mail list logo
