Re: PG 9.0 and standard_conforming_strings

-----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-----