Thread: 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