Обсуждение: Ambiguos OPERATOR items in pg_restore manifest file (was: [postgis-devel] utils/new_postgis_restore.pl)
Trying to exclude items from dumps of postgis-enabled databases we use pg_restore -l output and strip what we think belong to PostGIS. In doing so, Renzo found that for OPERATOR there are not enough informations to unambiguosly find it being part of PostGIS (see included mail snippet). Do you think this could be improved on the pg_restore side ? TIA. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html On Tue, Jul 12, 2011 at 12:15:37AM +0200, Renzo Kottmann wrote: > 2. Even more severe your exclusion list also excludes some postgis > specific operators like e.g. > OPERATOR && > or in the grep version > OPERATOR \(\w\+\) && > > Unfortunately, this also deletes operators from the ltree contrib which > I have in my dump. The problem is that in the manifest file the > operators of ltree and postgis are only distinguishable by oid. > Therefore, I included oids of the postgis operator in the pattern: > > 6836195 OPERATOR \(\w\+\) && > > This is of course unfortunately dump specific. I do not know if it is a > bug or feature of the pg_restore manifest file, but if it contained the > left- and right argument type of each operator, they would be easily > uniquely identifiable without the need to know the oid.
On Tue, Jul 12, 2011 at 9:18 AM, Sandro Santilli <strk@keybit.net> wrote: > Trying to exclude items from dumps of postgis-enabled databases > we use pg_restore -l output and strip what we think belong to PostGIS. > > In doing so, Renzo found that for OPERATOR there are not enough > informations to unambiguosly find it being part of PostGIS (see > included mail snippet). > > Do you think this could be improved on the pg_restore side ? In 9.1, we've added the concept of EXTENSIONs. I'm not sure whether PostGIS is planning to take advantage of this mechanism, but it's designed to solve exactly this problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 07/18/2011 05:25 PM, Robert Haas wrote: > On Tue, Jul 12, 2011 at 9:18 AM, Sandro Santilli <strk@keybit.net> wrote: >> Trying to exclude items from dumps of postgis-enabled databases >> we use pg_restore -l output and strip what we think belong to PostGIS. >> >> In doing so, Renzo found that for OPERATOR there are not enough >> informations to unambiguosly find it being part of PostGIS (see >> included mail snippet). >> >> Do you think this could be improved on the pg_restore side ? > In 9.1, we've added the concept of EXTENSIONs. I'm not sure whether > PostGIS is planning to take advantage of this mechanism, but it's > designed to solve exactly this problem. > The extensions concept will be a big step forward, no doubt. I just do not think that it solves the aforementioned problem. AFAIK the extension system will be available for 9.1 only. Then it would not be available for all kinds of dump/restore scenarios <9.1 (in my case from 8.4 to 9.0).
On Wed, Jul 20, 2011 at 8:24 AM, Renzo Kottmann <rkottman@mpi-bremen.de> wr= ote: > On 07/18/2011 05:25 PM, Robert Haas wrote: >> On Tue, Jul 12, 2011 at 9:18 AM, Sandro Santilli <strk@keybit.net> wrote: >>> Trying to exclude items from dumps of postgis-enabled databases >>> we use pg_restore -l output and strip what we think belong to PostGIS. >>> >>> In doing so, Renzo found that for OPERATOR there are not enough >>> informations to unambiguosly find it being part of PostGIS (see >>> included mail snippet). >>> >>> Do you think this could be improved on the pg_restore side ? >> In 9.1, we've added the concept of EXTENSIONs. =A0I'm not sure whether >> PostGIS is planning to take advantage of this mechanism, but it's >> designed to solve exactly this problem. >> > The extensions concept will be a big =A0step forward, no doubt. > > I just do not think that it solves the aforementioned problem. AFAIK > the extension system will be available for 9.1 only. Then it would not > be available for all kinds of dump/restore scenarios <9.1 (in my case > from 8.4 to 9.0). Yeah, that's a problem. The mechanism does include some magic that's supposed to help deal with this. The idea is -- first, you upgrade to 9.1 -- next, you say something like CREATE EXTENSION ename FROM unpackaged -- finally, you upgrade the extension using ALTER EXTENSION UPDATE. However, I'm not sure whether PostGIS is planning to support this mechanism, or whether it meets their needs. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company