| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Why is time with timezone 12 bytes? |
| Date: | 2010-09-23 19:20:17 |
| Message-ID: | 1285269397-sup-8036@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Excerpts from Robert Haas's message of jue sep 23 14:33:06 -0400 2010:
> I'm worried about how we're going to manage that. First, as
> pg_upgrade becomes more mature, the penalty for breaking on-disk
> compatibility gets a LOT bigger. I'd like to think that "the next
> time we break on-disk compatibility" means approximately "never", or
> at least "not for a very long time". Second, if we do decide to break
> it, how and when will we make that decision?
I liked your earlier suggestion: if somebody wants to pg_upgrade, he
needs to go to the latest minor release of their branch, run some
command to upgrade the on-disk format (say ALTER TABLE / SET TYPE), and
*then* upgrade.
Now if it was workable to handle floating-point datetimes to integer
datetimes this way, it would be excellent.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2010-09-23 19:30:24 | Re: Serializable Snapshot Isolation |
| Previous Message | Bruce Momjian | 2010-09-23 19:20:15 | pg_upgrade pain; was Re: Why is time with timezone 12 bytes? |