php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #60354 MYSQL_CLIENT_COMPRESS in php.ini
Submitted: 2011-11-22 03:02 UTC Modified: 2017-10-24 08:08 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:0 of 2 (0.0%)
From: spamik at yum dot pl Assigned:
Status: Open Package: MySQLi related
PHP Version: 5.3.8 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
19 - 6 = ?
Subscribe to this entry?

 
 [2011-11-22 03:02 UTC] spamik at yum dot pl 
Description:
------------
Using or not using mysql compression (or encryption) is a administrative decision, 
not decision that should be left for programmer as he usualy has no idea what is 
mysql configuration, what storage does it use and quite often this programmer just 
writes genuine aplications.
default for compression in mysql client (MYSQL_CLIENT_COMPRESS) should be settable 
in php.ini
http://pl2.php.net/manual/en/mysql.constants.php#mysql.client-flags

This would also to permanent connections but You made it into two diffrent 
commands so it would be more difficult.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-03-06 01:39 UTC] johannes@php.net
-Assigned To: +Assigned To: mysql
 [2012-03-06 01:39 UTC] johannes@php.net 
I'm not sure I agree. For compression the developer should know what data to expect. Encryption should be configured alongside with host/user/password which usually happens in the application.
Having more places overriding each others makes it hard to figure out which settings arebeing used in the end.
 [2012-03-20 09:41 UTC] uw@php.net 
I do not agree on the statement developers write genuie applications. Native interfaces are there to get most out of a specific interface/library from a specific application. As there is no security concern or severe performance impact, developer shall have full control. There's no need to differ from the logic of the underlying C library to ensure somewhat consistent behaviour among the same family of interfaces/libraries of a specific vendor.
 [2014-02-25 14:22 UTC] uw@php.net
-Package: MySQL related +Package: MySQLi related
 [2014-02-25 14:22 UTC] uw@php.net 
For ext/mysql it is certainly out of question. No updates for that one.
 [2017-10-24 08:08 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: mysql +Assigned To:
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Apr 24 23:01:34 2024 UTC