reassign owned to change the ownership for op class and family

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