Skip site navigation (1) Skip section navigation (2)

Re: reassign owned to change the ownership for op class and family

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Asko Tiidumaa <asko(dot)tiidumaa(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: reassign owned to change the ownership for op class and family
Date: 2010-07-04 02:37:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Jul 3, 2010 at 11:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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
The Enterprise Postgres Company

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-07-04 02:44:09
Subject: test_fsync output improvement
Previous:From: Alvaro HerreraDate: 2010-07-04 02:15:23
Subject: Re: _bt_parent_deletion_safe() isn't safe

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group