Re: [HACKERS] network_ops in 7.0 and pg_dump question
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] network_ops in 7.0 and pg_dump question |
Дата | |
Msg-id | 200002072052.PAA11461@candle.pha.pa.us обсуждение исходный текст |
Ответ на | network_ops in 7.0 and pg_dump question (Oleg Bartunov <oleg@sai.msu.su>) |
Ответы |
Re: [HACKERS] network_ops in 7.0 and pg_dump question
Re: [HACKERS] network_ops in 7.0 and pg_dump question |
Список | 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 по дате отправления: