On Wed, Aug 27, 2014 at 10:13 AM, Bruce Momjian 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 version 3
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 Mon, Aug 25, 2014 at 3:04 PM, Tom Lane wrote:
> Bruce Momjian 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,
>>
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 s
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 wrote:
> > > Magnus Hagander wrote:
> >
> > >>> I vote for discarding 8.3 support in pg_upgrade. There are already
> > >>> enough limitations on pg_u
On Mon, Aug 25, 2014 at 03:04:52PM -0400, Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 same version r
On Mon, Aug 25, 2014 at 06:34:12AM -0700, Kevin Grittner wrote:
> Bernd Helmle wrote:
> > Magnus Hagander 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 t
Bernd Helmle wrote:
> Magnus Hagander 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
>>> rope.
>>
>> +1. 8.3 ha
--On 21. August 2014 22:08:58 +0200 Magnus Hagander
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
rope.
+1. 8.3 has
On Thu, Aug 21, 2014 at 10:07 PM, Tom Lane wrote:
> Bruce Momjian 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 complex than I liked. Another
Bruce Momjian 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 patch preven
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
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
Now that everyone is happy with how pg_upgrade_support uses global
variables to set preserved oids (or at least has no better ideas), I
think it is time to lock down this usage to prevent future breakage.
Specifically, the first attached patch causes pg_upgrade_support
functions to throw errors wh
15 matches
Mail list logo
