MySQL Bugs: #12377: Item_date_add_interval needs to have the int

Bug #12377	Item_date_add_interval needs to have the int_type member as Public
Submitted:	4 Aug 2005 12:21	Modified:	10 Nov 2005 16:30
Reporter:	Philip Stoev	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S4 (Feature request)
Version:	4.1	OS:	Linux (Linux)
Assigned to:	Guilhem Bichot	CPU Architecture:	Any

Description:
Hello,

Can you please make the int_type member of Item_date_add_interval and Item_extract classes Public so that those can be queries by third-party code. Those members are currently private, which means that it is impossible for external code to determine the interval type of a DATE_ADD() expression.

How to repeat:

Item_date_add_interval * date_add_interval;
printf("%i",date_add_interval->int_type);

The second line results in an error because int_type is protected.

Suggested fix:
Please make int_type public or provide a method for querying its value.

Providing this one-line change to the code will help the following open-source project:

http://search.cpan.org/~philips/DBIx-MyParse-0.20/

If you like the idea of the project, kindly please spend a minute of your time to fix the Item_date_add_interval class.

This is not a bug, but a feature request. It has been forwarded to the proper person to contact you with the details.

Regards

Hi Philip,
Could you please attach (using the "Files" section of this bug report) a diff of the changes you would like to see applied to the latest MySQL 4.1 source and a diff of the changes you would like to see applied to the latest 5.0 source, so that we can check that it's doable.

This is a patch against 4.14 providing the requested functionality.

Attachment: patch-against-4.14.txt (text/plain), 2.68 KiB.

Thanks for the response, a patch against 4.14 has been uploaded. Please let me know if it works for you. If it does, I will do the same against the latest 5.0 release.

Thanks again for the effort, I really appreciate that.

Hi Philip,
Thanks, got the patch. I think what you want is to be able to read the class members, you don't need to be able to modify them, right? so I'd prefer if instead of declaring them "public", I leave them "private" but add public methods for reading them, like:
const LEX_STRING* Item_func_set_user_var::get_name() { return &name; }
const LEX_STRING* Item_func_get_user_var::get_name() { return &name; }
const CHARSET_INFO* Item_func_conv_charset::get_conv_charset() {return conv_charset; }
const interval_type Item_date_add_interval::get_int_type() { return int_type; }
const bool Item_date_add_interval::get_date_sub_interval { return date_sub_interval; }
const interval_type Item_extract::get_int_type() { return int_type; }
const timestamp_type Item_func_get_format::get_type() { return type; }
For us, it would be better this way. Because if I make the members private, it increases the risk that we MySQL developers feel allowed to change them - creating bugs.
Sounds ok this way?

Thanks, that approach with the public methods will work, however I think that almost all of the classes starting with Item_ are all public anyway and I am already using them the way they are. The classes mentioned in the patch appear to be exceptions from the general all-public coding style so it appears to me that by applying my patch those classes will be brought back to the common style. I believe that the style was broken as more functionality was added to existing SQL operators and whoever added the functionality placed the required members above the public: line in the class declaration.

Hi Philip,
I'll check that. First I have to work on some urgent bugfixing, I will get back to this afterwards.

Hi Philip,
I'll soon apply your patch verbatim to 4.1. Please could you also upload the patch for what you need in 5.0?
Thanks.

I will need a few days to prepare a patch against 5.x since I need to examine all the Item_* classes, including any newly-added ones.  Thank you again for your cooperation.

This is the patch against 5.0.15.

Attachment: patch-5.0.15.txt (text/plain), 2.64 KiB.

I have uploaded a patch against 5.0.15. Again, thank you very much for your cooperation.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/32139

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/32140

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Hello Philip,
Your code changes will appear in 5.0.16 (our current GA release, to be released in a few days) and in 4.1.16 (I don't know when it will be released, it's our older GA release), I have just committed them.
I put a comment near the changed lines to say "keep this class member public".
But to protect against some class member which would be moved from public to private by a colleague one day, I think it could be a good idea for you to regularly pull our development tree
(http://dev.mysql.com/doc/refman/5.0/en/installing-source-tree.html)
so that you notice if a change in this tree suddenly makes MyParse fail to compile, and can report it early.
Good luck, thanks for using MySQL :)
Docs team: nothing to document, this is just an internal code minor change.

Thank you very much for your cooperation. I really appreciate it.