Re: PG 9.0 and standard_conforming_strings
От | Greg Sabino Mullane |
---|---|
Тема | Re: PG 9.0 and standard_conforming_strings |
Дата | |
Msg-id | 87ebd6cf7535a393dde89ddddd4955c3@biglumber.com обсуждение исходный текст |
Ответ на | Re: PG 9.0 and standard_conforming_strings (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: PG 9.0 and standard_conforming_strings
(Robert Haas <robertmhaas@gmail.com>)
Re: PG 9.0 and standard_conforming_strings (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> Perl (DBD::Pg anyway) has been compatible since May 2008. > I would interpret that to mean that there is a significant possibility > that a too-old DBD::Pg could get used with a new PostgreSQL, and > therefore we shouldn't change anything for 9.0. May 2008 is not that > long ago, especially for people running systems like RHEL with > five-year major release cycles. That's a silly conclusion. Applications and drivers are always going to lag behind. If someone is having a problem, they either upgrade their DBD::Pg or flip the GUC. Are you really saying we should wait until 2008 +5 years (2013!) before making this change? Wouldn't we have to wait five years past the point when *all* drivers are compatible by your definition? > I am not sure I really understand why anyone is a rush to make this > change. What harm is being done by the status quo? What benefit do > we get out of changing the default? The major argument that has been > offered so far is that "if we don't change it now, we never will", but > I don't believe that the tenor of this discussion supports the > contention that Tom or anyone else never wants to make this change. It's hardly a rush (the GUC has been around and is being used in production), and the benefit is standards compatibility, something we strive for around here. I personally don't agree with the "now or never" argument, but I do agree with the "dot zero release is a good time for changes like this" argument. > It also seems to overlook the fact that we are STILL dealing with the > fallout from this change in the core code; Tom gave examples upthread > of changes that are being released for the first time *in 9.0* to > address problems created by this transition. And that is just the > core code; we have to expect that third-party code will lag behind. Which fallout are we still dealing with? Are you saying that the developers are not up to the challenge of handling this before 9.0 is released? (If this were anything more than a simple boolean GUC fix, I would be in your corner). Yes, third-party code will lag behind, but, again, that's the nature of the game. We didn't wait for every driver, app, and script to support schemas before we added them in 7.4, for example. We certainly didn't wait for applications to be implicit casting ready before 8.3, to (over?)use another example. - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201002031342 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktpxEUACgkQvJuQZxSWSsibFwCeJzeQzUTBFwqHQ451Y23cbLfT 4UUAoK/2Sg/pxq5ipdB2B2ekfzQgW0cT =5/gh -----END PGP SIGNATURE-----
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: Recent vendor SSL renegotiation patches break PostgreSQL