Thread

  1. reassign owned to change the ownership for op class and family

    Asko Tiidumaa <asko.tiidumaa@gmail.com> — 2010-07-01T15:19:46Z

    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
    
  2. Re: reassign owned to change the ownership for op class and family

    Robert Haas <robertmhaas@gmail.com> — 2010-07-03T14:13:09Z

    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
    
    
  3. Re: reassign owned to change the ownership for op class and family

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-07-03T15:47:53Z

    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
    
    
  4. Re: reassign owned to change the ownership for op class and family

    Robert Haas <robertmhaas@gmail.com> — 2010-07-04T02:37:28Z

    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