Re: Extensions versus pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Extensions versus pg_upgrade
Date
Msg-id 21596.1297186247@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extensions versus pg_upgrade  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Extensions versus pg_upgrade  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Now what?

> What would be the problem with pg_upgrade acting the same as a
> dump&reload cycle as far as extensions are concerned?

Um, how about "it doesn't work"?

The reason that data type OIDs have to be preserved, for example, is
that they might be out on disk.  Suppose that you have the cube
extension installed and there are some user tables containing columns of
type cube[].  Those arrays are going to have type cube's OID embedded in
them.  If cube has a different OID after pg_upgrade then the arrays are
broken.

Even letting an extension script run and create data types that weren't
there at all before is problematic, since those types could easily claim
OIDs that need to be reserved for pre-existing types that appear later
in the dump script.

Similar issues arise for the other cases where pg_upgrade is forcing OID
assignments; it's not doing that just for fun.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Euler Taveira de Oliveira
Date:
Subject: Re: Allow pg_archivecleanup to ignore extensions
Next
From: Alex Hunsaker
Date:
Subject: Re: arrays as pl/perl input arguments [PATCH]