Josh Berkus <josh@agliodbs.com> writes: > Peter, >> What difference would pg_dump make? > For many user's databases ... many more than any previous version after > 7.3 ... using the old version's pg_dump *will not load* into 8.3. Unless you > restore the casts. Please provide a concrete example. > Should I be discussing this on a different list? If you are looking for code changes, neither docs nor advocacy are suitable forums. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Josh Berkus <josh@agliodbs.com> writes: > Hmmm. I don't feel like it contains a clear warning, though. We need a > statement like: > Some users may encounter issues upgrading due to the changes in handling > data type casts. If you suspect that your schema or application may not > be handling data type comparisons cleanly, you are strongly urged to test > for casting error messages before upgrading your production server. When have we ever suggested that people *shouldn't* test their apps before committing to a major version update? I think the whole thing has been significantly overblown. We have made incompatible changes bigger than this one --- and, often, harder to find let alone fix --- in almost every major release. This one you can at least be pretty sure that you will get an error, and not a silent change in behavior, if you fall foul of it. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

"Joshua D. Drake" <jd@commandprompt.com> writes: > Honestly, I think you are underestimating this problem. The reason I'm underestimating the problem is that neither you nor Josh have provided one iota of evidence to support your position that the sky is falling. When I look back at the release notes for the past several major releases, I see lots of incompatibilities that look far worse than this one. In many cases there were fairly subtle semantic changes that would cause a query to still run, but deliver different answers than before. Now that is the sort of thing that would maybe justify banners on the rooftops, but as far as I recall we have always assumed that our users were adult enough to read the compatibility warnings in the release notes. Heck, we have created bigger compatibility problems in *minor* releases; the security-related tightening of multibyte encoding validity checks caused a lot more problems for a lot more people (and with a lot less notice) than I believe this change will do. What we've got here is a case where certain people who were doing fairly squirrely things will see errors that compel them to insert explicit casts to make their intent clear. This won't even create a backwards compatibility problem for them: the correctly-casted code will still work in prior releases too. To me this looks comparable to, say, the removal of LIMIT #,# syntax in favor of LIMIT/OFFSET in 7.3. I fail to see why this is a major problem; and merely asserting that it is one isn't going to change my mind. Can you point to something like a major application that will be broken and can't easily be fixed? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match