Opened 12 years ago
Closed 12 years ago
#1368 closed defect (fixed)
ERROR: operator does not exist: hstore @ hstore
| Reported by: | strk | Owned by: | strk |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 2.0.0 |
| Component: | postgis | Version: | master |
| Keywords: | Cc: |
Description
The *postgis_restore.pl family of function try to avoid restoring items which may have been installed by postgis, but for operators the custom dump manifest doesn't contain enough information to tell if an operator belongs to postgis or not.
In this case, the hstore module installs a few operators which have the same name as the ones we use for spatial types, thus *postgis_restore.pl traps them and you end up with those operators not clearely restored.
Not necessarely a big deal, if you can restore those by re-enabling hstore in your db, but they could be used by other items in your dump (views?)
Change History (2)
comment:1 by , 12 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
r8365 fixes this. Now that I feel the superpowers I'll move on to also deal with constraints 
Note:
See TracTickets
for help on using tickets.
I'm adding to new_postgis_restore.pl the logic already present in postgis_restore.pl about OPERATORS. In the old script, this issue was well known so the skip was performed at the ASCII level rather than at the MANIFEST level. Let's see where we get from there.