MySQL Bugs: #57229: not clear if 'profiling' and 'have_profiling ' variables are synonyms in 5.5

Bug #57229	not clear if 'profiling' and 'have_profiling ' variables are synonyms in 5.5
Submitted:	4 Oct 2010 21:27	Modified:	16 Oct 2012 5:24
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S3 (Non-critical)
Version:	5.5.6, 5.5.7-bzr	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	qc, regression

Description:
This is a follow-up on an earlier report: http://bugs.mysql.com/bug.php?id=48344

The original report dealed with an inconsistency between 5.0 and 5.1 servers. I added a few comments regarding 5.5 a few days ago. They read (with a few clarifications):

There is a regression in 5.5!

SELECT VERSION(); -- 5.5.6-rc

SHOW GLOBAL VARIABLES LIKE '%prof%';
/*
Variable_name Value
---------------------- ------
have_profiling YES
profiling OFF
profiling_history_size 15
*/

SELECT VERSION(); -- 5.1.51-community

SHOW GLOBAL VARIABLES LIKE '%prof%';
/*
Variable_name Value
---------------------- ------
profiling OFF
profiling_history_size 15
*/

So what now?

2)
OK .. documentation at
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html
.. lists both (unlike what http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html did)

have_profiling:

YES if statement profiling is enabled, NO if not. See Section 12.4.5.31, “SHOW PROFILE Syntax”.

profiling:

If set to 0 (the default), statement profiling is disabled. If set to 1, statement profiling is enabled and the SHOW PROFILES and SHOW PROFILE statements provide access to profiling information. See Section 12.4.5.32, “SHOW PROFILES Syntax”.

If MySQL wants to keep both for some backwards compatibility reason I have no issues. But

1) they must then be *complete synonyms*? I so docs should state this. And if they are not *complete synonyms* docs should explain the difference.
2) one is described using 0|1 parameters (even though SHOW returns ON|OFF) and the other using YES|NO parameters and they refer section 12.4.5.31 and section 12.4.5.32 respectively what is a minor inconsistency in docs.

It has always been somewhat unclear to me if comments to old reports (also to *verified* reports) are read or not. I mostly have the impression that they are not.

If you want to mark as 'duplicate' I have no issue - if only the main scope of this discussion now focus'es on clarifying the meaning of both variables in 5.5. But probably marking the old one as 'wont fix' (as 5.0 is out of support) and this one as 'verified' seems to me to be the better solution.

Experiments tell me that 'profiling' decides (alone) whether the server supports PROFILING. The 'query profile' feature of (our) SQLyog ULTIMATE program only considers 'profiling' variable (and not 'have _profiling' at all) and works as expected with 5.5x.

How to repeat:
see above

Suggested fix:
see above

fixed typo in synopsis.

.. or maybe rather 'have_profiling' is completely redundant and not used at all?

Indeed, this is strange to have have_profiling back in 5.5. I do not think it is needed.

have_profiling is redundant, leads to no action and needs to go. Probably just a bad merge.

Analysis by the dev team:

have_profiling is a *read-only* variable that shows whether the profiling
code is present in MySQL or not.

"profiling" is a *read-write* variable that controls whether profiling
information is actually collected or not.

So they're not the same thing (despite the similarly sounding names).

Hence closing as "not a bug".