From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Collation-aware comparisons in GIN opclasses |
Date: | 2015-03-19 17:17:12 |
Message-ID: | 20150319171712.GH6061@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Sep 28, 2014 at 10:33:33PM -0400, Bruce Momjian wrote:
> On Mon, Sep 15, 2014 at 03:42:20PM -0700, Peter Geoghegan wrote:
> > On Mon, Sep 15, 2014 at 12:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > No. And we don't know how to change the default opclass without
> > > breaking things, either.
> >
> > Is there a page on the Wiki along the lines of "things that we would
> > like to change if ever there is a substantial change in on-disk format
> > that will break pg_upgrade"? ISTM that we should be intelligently
> > saving those some place, just as Redhat presumably save up
> > ABI-breakage over many years for the next major release of RHEL.
> > Alexander's complaint is a good example of such a change, IMV. Isn't
> > it more or less expected that the day will come when we'll make a
> > clean break?
>
> It is on the TODO page under pg_upgrade:
>
> Desired changes that would prevent upgrades with pg_upgrade
Item added to TODO list.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Shchukin | 2015-03-19 17:30:44 | Re: [GENERAL] Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary |
Previous Message | Robert Haas | 2015-03-19 17:08:40 | Re: flags argument for dsm_create |