From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] network_ops in 7.0 and pg_dump question |
Date: | 2000-02-07 20:52:01 |
Message-ID: | 200002072052.PAA11461@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2000-02-07 20:53:29 | Re: [HACKERS] An introduction and a plea ... |
Previous Message | Oleg Bartunov | 2000-02-07 20:31:22 | network_ops in 7.0 and pg_dump question |