Ambiguos OPERATOR items in pg_restore manifest file (was: [postgis-devel] utils/new_postgis_restore.pl)

From: Sandro Santilli <strk(at)keybit(dot)net>
To: pgsql-bugs(at)postgresql(dot)org
Cc: rkottman(at)mpi-bremen(dot)de, PostGIS Development Discussion <postgis-devel(at)postgis(dot)refractions(dot)net>, Sebastian Groß <sgross(at)mpi-bremen(dot)de>
Subject: Ambiguos OPERATOR items in pg_restore manifest file (was: [postgis-devel] utils/new_postgis_restore.pl)
Date: 2011-07-12 13:18:11
Message-ID: 20110712131811.GH13590@gnash
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2011-07-12 14:28:24 Re: Window function bug
Previous Message Daniele Varrazzo 2011-07-12 11:37:41 extract(epoch from infinity) is not 0