Re: Collations and Replication; Next Steps
От | Peter Geoghegan |
---|---|
Тема | Re: Collations and Replication; Next Steps |
Дата | |
Msg-id | CAM3SWZQZ_-QxyKagV1ut9CY01jjyiS_FaN9Cqji09HCVCLvVKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collations and Replication; Next Steps (Greg Stark <stark@mit.edu>) |
Список | pgsql-hackers |
On Wed, Sep 17, 2014 at 7:46 AM, Greg Stark <stark@mit.edu> wrote: > You could have a problem if you have an expression index on (timestamp > AT TIME ZONE '...'). I may have the expression slightly wrong but I > believe it is posisble to write an immutable expression that depends > on the tzdata data as long as it doesn't depend on not the user's > current time zone (which would be stable but not immutable). The > actual likelihood of that situation might be much lower and the > ability to avoid it higher but in theory I think Peter's right that > it's the same class of problem. Really? If you have an "IMMUTABLE" expression predicated on something that isn't immutable, then it isn't actually immutable, regardless of the ability of Postgres to determine that. It's that simple. So, if that's true, then it sounds like a bug to me. I didn't check, but I think that AT TIME ZONE just changes the display format, and the relevant output function is only stable, and so this shouldn't be a problem. > Peter G, could go into more detail about collation versioning? What > would the implications be for Postgres? Well, I think one implication might be that Postgres won't start, just because you updated the OS (we have no way to get back results consistent with the old collation file, I would think). At least your database isn't corrupt, but that's still a really bad loss of availability. This makes me lean towards pursuing ICU support as part of any versioning scheme. There is a reason why everyone else does something similar. Apparently DB2 uses ICU. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: