FAQ
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.

Search Discussions

  • Robert Haas at Jul 18, 2011 at 3:25 pm

    On Tue, Jul 12, 2011 at 9:18 AM, Sandro Santilli 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
  • Renzo Kottmann at Jul 20, 2011 at 12:31 pm

    On 07/18/2011 05:25 PM, Robert Haas wrote:
    On Tue, Jul 12, 2011 at 9:18 AM, Sandro Santilli 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).
  • Robert Haas at Jul 27, 2011 at 7:21 pm

    On Wed, Jul 20, 2011 at 8:24 AM, Renzo Kottmann wrote:
    On 07/18/2011 05:25 PM, Robert Haas wrote:
    On Tue, Jul 12, 2011 at 9:18 AM, Sandro Santilli 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).
    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.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise PostgreSQL Company

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-bugs @
categoriespostgresql
postedJul 12, '11 at 1:18p
activeJul 27, '11 at 7:21p
posts4
users3
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase