Re: contrib loose ends: 9.0 to 9.1 incompatibilities
От | Robert Haas |
---|---|
Тема | Re: contrib loose ends: 9.0 to 9.1 incompatibilities |
Дата | |
Msg-id | AANLkTinnCx_7eUANc3UgwLK6cr7gOBGtsfbkaikyviyv@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: contrib loose ends: 9.0 to 9.1 incompatibilities (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: contrib loose ends: 9.0 to 9.1 incompatibilities
|
Список | pgsql-hackers |
On Fri, Feb 18, 2011 at 12:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, Feb 17, 2011 at 9:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> 2. intarray and tsearch2 use some core support functions in their >>> GIN opclasses, and those support functions changed signatures in 9.1. >>> The current solution to this involves having stub functions in core >>> with the old signatures; when you do an upgrade from the 9.0 version >>> of one of these contrib modules, its opclass will be pointing at the >>> stub version instead of the preferred version. I guess we could fix >>> that with a direct UPDATE on pg_amproc but I'm not sure that's a >>> good idea. Note these functions aren't actually *members* of the >>> extensions, just things it references, so the odds of future trouble >>> seem pretty small. On the other hand, if we don't do this, it's >>> unclear when we'll ever be able to get rid of the stubs. >>> >>> Comments? > >> ISTM that the pg_amproc entries are part of the operator class, which >> is owned by the extension. So it's the upgrade script's job to leave >> the operator class in the right state. > > OK, I held my nose and inserted UPDATE commands to make the opclasses > match. AFAICT the only remaining discrepancy between contrib modules > made fresh in 9.1 and those updated from 9.0 is the question of citext's > collation property, which as noted in the other thread is not worth > dealing with until the collation stuff is a bit better thought out. OK. Thanks for nailing all of this down - that's got to have been a heck of a job. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: