Re: [HACKERS] network_ops in 7.0 and pg_dump question - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] network_ops in 7.0 and pg_dump question
Date
Msg-id 200002072052.PAA11461@candle.pha.pa.us
Whole thread Raw
In response to network_ops in 7.0 and pg_dump question  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: [HACKERS] network_ops in 7.0 and pg_dump question
Re: [HACKERS] network_ops in 7.0 and pg_dump question
List pgsql-hackers
> Hi,
> 
> what's happen with network_ops in current CVS ?
> I just synced sources and couldn't load dump from 6.5.3 - 
> problem occures on 
> CREATE  INDEX "face_key" on "face" using btree ( "eid" "int4_ops", "ip" "network_ops" );
> 
> The message I got:
> CREATE
> ERROR:  DefineIndex: network_ops class not found
> 

Oops, my fault.  There was some confusing links in the catalog for the
ip/cidr types.  They pointed to the same *ops, which made the table
non-unique, so the cache would grab a random matching entry.  The new
system has separate *ops for each type.  We were basically using the
cache on a non-unique entry.  We would grab the first match.  The new
code uses the same underlying functions, but moves the duplication down
one level.

Now, how to convert these?  Not supplying the ops works fine, but
pg_dump supplies the ops.  Maybe in gram.y, if they supply network_ops,
we should just remove that from being passed to the backend for a few
releases.  Comments?



--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] An introduction and a plea ...
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] network_ops in 7.0 and pg_dump question