Prev: Anti pillules
Next: [HACKERS] Why is vacuum_defer_cleanup_age PGC_USERSET?
From: Robert Haas on 3 Jul 2010 10:13
On Thu, Jul 1, 2010 at 11:19 AM, Asko Tiidumaa <asko.tiidumaa(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 3 Jul 2010 11:47
Robert Haas <robertmhaas(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: Anti pillules
Next: [HACKERS] Why is vacuum_defer_cleanup_age PGC_USERSET?