On Jul 22, 2009, at 1:11 PM, Robert Haas wrote:
If you keep an old and a new version of the datatype, you can't
upgrade a tuple at a time, but you can at least upgrade one column at
a time, which is still better than a kick in the head.
And as long as you're willing to deprecate how far back
On Jul 23, 2009, at 2:44 AM, David E. Wheeler da...@kineticode.com
wrote:
On Jul 22, 2009, at 1:11 PM, Robert Haas wrote:
If you keep an old and a new version of the datatype, you can't
upgrade a tuple at a time, but you can at least upgrade one column at
a time, which is still better than
Robert Haas robertmh...@gmail.com writes:
On Jul 23, 2009, at 2:44 AM, David E. Wheeler da...@kineticode.com
wrote:
Well, it depends. If there could be some sort of defined interface for
pg_migrator could call to migrate any data type (this issue applies
mainly to types, yes?), then an
On Jul 23, 2009, at 4:08, Robert Haas robertmh...@gmail.com wrote:
Yes... but if and just can paper over a good deal of complexity,
and it's not clear to me that there's any compensating advantage.
It seems reasonable not to worry about this issue in the first rev, or
at least not to let
On Thu, Jul 23, 2009 at 11:05 AM, David E. Wheelerda...@kineticode.com wrote:
On Jul 23, 2009, at 4:08, Robert Haas robertmh...@gmail.com wrote:
Yes... but if and just can paper over a good deal of complexity, and
it's not clear to me that there's any compensating advantage.
It seems
On Tue, Jul 21, 2009 at 8:56 PM, Robert Haasrobertmh...@gmail.com wrote:
A decent module infrastructure is probably not going to fix this
problem unless it links with -ldwiw. There are really only two
options here:
- Keep the old version around for compatibility and add a new version
that
