Обсуждение: reassign owned to change the ownership for op class and family
Currently REASSIGN OWNED complains "unexpected classid" for operator class and family. For example, create two users, user1 and user2 under user1: create type oxetype as enum ('oxe1'); create operator class oxeops default for type oxetype using btree as function 1 array_lower(anyarray,integer); and then observe "unexpected classid" error: reassign owned by user1 to user2 So I propose a patch that goes against head, and it would be great to get it backported to at least 8.3 branch Comments? Asko Tiidumaa --- Skype, Sr DBA
Вложения
On Thu, Jul 1, 2010 at 11:19 AM, Asko Tiidumaa <asko.tiidumaa@gmail.com> wrote: > Currently REASSIGN OWNED complains "unexpected classid" for operator > class and family. > > For example, > > create two users, user1 and user2 > > under user1: > create type oxetype as enum ('oxe1'); > create operator class oxeops > default for type oxetype using btree as > function 1 array_lower(anyarray,integer); > > and then observe "unexpected classid" error: > reassign owned by user1 to user2 > > So I propose a patch that goes against head, and it would be great to > get it backported to at least 8.3 branch > > Comments? Committed, with minor adjustments. This is actually against 8.3; it needs to use the new syscache macros in head (which I did). http://archives.postgresql.org/pgsql-committers/2010-02/msg00174.php I wonder if we should think about back-patching just the syscache.h portion of that patch. It would simplify back-patching, and might make life easier for people trying to write extensions that are compatible with multiple PG versions, too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas <robertmhaas@gmail.com> writes: > http://archives.postgresql.org/pgsql-committers/2010-02/msg00174.php > I wonder if we should think about back-patching just the syscache.h > portion of that patch. It would simplify back-patching, and might > make life easier for people trying to write extensions that are > compatible with multiple PG versions, too. Not sure. Maybe it will make back-patching a bit easier, but we don't normally consider back-patching cosmetic changes, which is what this really is. I don't buy the suggestion that third-party extensions would be able to rely on it across versions. They can't know if they're going to be compiled against the latest minor release or not. So it's just a question of whether it'll improve matters enough for our own back-patches. regards, tom lane
On Sat, Jul 3, 2010 at 11:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> http://archives.postgresql.org/pgsql-committers/2010-02/msg00174.php > >> I wonder if we should think about back-patching just the syscache.h >> portion of that patch. It would simplify back-patching, and might >> make life easier for people trying to write extensions that are >> compatible with multiple PG versions, too. > > Not sure. Maybe it will make back-patching a bit easier, but we don't > normally consider back-patching cosmetic changes, which is what this > really is. > > I don't buy the suggestion that third-party extensions would be able > to rely on it across versions. They can't know if they're going to be > compiled against the latest minor release or not. So it's just a > question of whether it'll improve matters enough for our own > back-patches. Well, you could make all the same arguments about backpatching hstore(text, text) which you advocated, and we did, not long ago. I don't actually feel terribly strongly about it; I just thought I'd run it up the flagpole and see if anyone saluted. The day of reckoning will come if and when we commit the patch to change syscaches to 5 keys. At that point extension authors are going to have a real pain in the ass on their hands. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company