From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Planning incompatibilities for Postgres 10.0 |
Date: | 2013-05-27 12:26:48 |
Message-ID: | 20130527122648.GI8597@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> If I had to _guess_, I would say users who are using the default storage
> manager would still be able to use pg_upgrade, and those using
> non-default storage managers perhaps can't.
That would make sense.
> But, again, this is all so hypothetical that it doesn't seem worth
> talking about.
Having a specific list of "these are the things we want to change, and
why, and here is why pg_upgrade can't support it" would be much more
useful to work from, I agree.
That said, many discussions and ideas do get shut down, perhaps too
early, because of pg_upgrade considerations. If we had a plan to have
an incompatible release in the future, those ideas and discussions might
be able to progress to a point where we determine it's worth it to take
the pain of a non-pg_upgrade-supported release. That's a bit of a
stretch, in my view, but I suppose it's possible. Even so though, I
would suggest that we put together a wiki page to list out those items
and encourage people to add to such a list; perhaps having an item on
that list would make discussion about it progress beyond "it breaks
pg_upgrade".
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2013-05-27 12:26:53 | Re: PostgreSQL Process memory architecture |
Previous Message | Atri Sharma | 2013-05-27 12:23:42 | Re: PostgreSQL Process memory architecture |