Hi,
Which functions were chosen to be in these two arrays and for what reasons? Are these the functions that look like most used, or should these lists contain everything that can be used on Insert tab (functions that can take string arguments)?
Le 2011-06-30 15:27, Piotr Przybylski a écrit :
Hi,
Which functions were chosen to be in these two arrays and for what reasons? Are these the functions that look like most used, or should these lists contain everything that can be used on Insert tab (functions that can take string arguments)?
These are functions that take one argument (string or numeric, depending on the function).
I don't believe that an effort has been made to keep the list up to date with all the possibilities or to verify which function is available on a specific MySQL version.
2011/6/30 Marc Delisle marc@infomarc.info:
Le 2011-06-30 15:27, Piotr Przybylski a écrit :
Hi,
Which functions were chosen to be in these two arrays and for what reasons? Are these the functions that look like most used, or should these lists contain everything that can be used on Insert tab (functions that can take string arguments)?
These are functions that take one argument (string or numeric, depending on the function).
You mean zero or one?
I don't believe that an effort has been made to keep the list up to date with all the possibilities or to verify which function is available on a specific MySQL version.
I am asking because I started comparing this list with Drizzle, and MySQL 4.1 has some functions that aren't there. I will go through MySQL 5.0 manual and update these lists.
Le 2011-06-30 17:11, Piotr Przybylski a écrit :
2011/6/30 Marc Delislemarc@infomarc.info:
Le 2011-06-30 15:27, Piotr Przybylski a écrit :
Hi,
Which functions were chosen to be in these two arrays and for what reasons? Are these the functions that look like most used, or should these lists contain everything that can be used on Insert tab (functions that can take string arguments)?
These are functions that take one argument (string or numeric, depending on the function).
You mean zero or one?
One; this is used in Insert (or edit) and uses the provided value as the argument.
I don't believe that an effort has been made to keep the list up to date with all the possibilities or to verify which function is available on a specific MySQL version.
I am asking because I started comparing this list with Drizzle, and MySQL 4.1 has some functions that aren't there. I will go through MySQL 5.0 manual and update these lists.
MySQL 4.1 is not important for phpMyAdmin 3.5 because the minimum supported version is MySQL 5.0.
2011/6/30 Marc Delisle marc@infomarc.info:
Le 2011-06-30 17:11, Piotr Przybylski a écrit :
2011/6/30 Marc Delislemarc@infomarc.info:
Le 2011-06-30 15:27, Piotr Przybylski a écrit :
Hi,
Which functions were chosen to be in these two arrays and for what reasons? Are these the functions that look like most used, or should these lists contain everything that can be used on Insert tab (functions that can take string arguments)?
These are functions that take one argument (string or numeric, depending on the function).
You mean zero or one?
One; this is used in Insert (or edit) and uses the provided value as the argument.
CURTIME and UTC_* are there too and they take no arguments.
Le 2011-06-30 17:34, Piotr Przybylski a écrit :
2011/6/30 Marc Delislemarc@infomarc.info:
Le 2011-06-30 17:11, Piotr Przybylski a écrit :
2011/6/30 Marc Delislemarc@infomarc.info:
Le 2011-06-30 15:27, Piotr Przybylski a écrit :
Hi,
Which functions were chosen to be in these two arrays and for what reasons? Are these the functions that look like most used, or should these lists contain everything that can be used on Insert tab (functions that can take string arguments)?
These are functions that take one argument (string or numeric, depending on the function).
You mean zero or one?
One; this is used in Insert (or edit) and uses the provided value as the argument.
CURTIME and UTC_* are there too and they take no arguments.
You're right, some functions can take no arguments. CURDATE() is also like that.
On a related topic - do we need these to be configurable in config.inc.php? I think these could be moved to a separate file (eg. libraries/mysql.data.php), along with everything that is in config.default.php under "MySQL settings" comment. I see no reason anybody would want to change these, unless you desperately need a user defined function available in phpMyAdmin interface.
Le 2011-07-01 18:57, Piotr Przybylski a écrit :
On a related topic - do we need these to be configurable in config.inc.php? I think these could be moved to a separate file (eg. libraries/mysql.data.php), along with everything that is in config.default.php under "MySQL settings" comment. I see no reason anybody would want to change these, unless you desperately need a user defined function available in phpMyAdmin interface.
Piotr, is this a problem to leave them configurable? Some users or providers probably changed the configuration since it is configurable.
2011/7/2 Marc Delisle marc@infomarc.info:
Le 2011-07-01 18:57, Piotr Przybylski a écrit :
On a related topic - do we need these to be configurable in config.inc.php? I think these could be moved to a separate file (eg. libraries/mysql.data.php), along with everything that is in config.default.php under "MySQL settings" comment. I see no reason anybody would want to change these, unless you desperately need a user defined function available in phpMyAdmin interface.
Piotr, is this a problem to leave them configurable? Some users or providers probably changed the configuration since it is configurable.
No, I will just have to do a bit more work to filter this for Drizzle :)
I was just wondering, because the only use case I can think of is to add custom native functions.
Le 2011-07-02 16:09, Piotr Przybylski a écrit :
2011/7/2 Marc Delislemarc@infomarc.info:
Le 2011-07-01 18:57, Piotr Przybylski a écrit :
On a related topic - do we need these to be configurable in config.inc.php? I think these could be moved to a separate file (eg. libraries/mysql.data.php), along with everything that is in config.default.php under "MySQL settings" comment. I see no reason anybody would want to change these, unless you desperately need a user defined function available in phpMyAdmin interface.
Piotr, is this a problem to leave them configurable? Some users or providers probably changed the configuration since it is configurable.
No, I will just have to do a bit more work to filter this for Drizzle :)
I was just wondering, because the only use case I can think of is to add custom native functions.
It can be also to remove unused functions in order to shorten the lists.
By the way, my assumption about the need of some for leaving it configurable is just an assumption.
I suggest asking about this on the phpmyadmin-users list.
2011/7/2 Marc Delisle marc@infomarc.info:
Le 2011-07-02 16:09, Piotr Przybylski a écrit :
2011/7/2 Marc Delislemarc@infomarc.info:
Le 2011-07-01 18:57, Piotr Przybylski a écrit :
On a related topic - do we need these to be configurable in config.inc.php? I think these could be moved to a separate file (eg. libraries/mysql.data.php), along with everything that is in config.default.php under "MySQL settings" comment. I see no reason anybody would want to change these, unless you desperately need a user defined function available in phpMyAdmin interface.
Piotr, is this a problem to leave them configurable? Some users or providers probably changed the configuration since it is configurable.
No, I will just have to do a bit more work to filter this for Drizzle :)
I was just wondering, because the only use case I can think of is to add custom native functions.
It can be also to remove unused functions in order to shorten the lists.
By the way, my assumption about the need of some for leaving it configurable is just an assumption.
I suggest asking about this on the phpmyadmin-users list.
Adding Drizzle functions look messy [1] and I am not satisfied with how this turned out. Here's an idea I would like to try, which would make it cleaner while still leaving these arrays configurable the same way as they are now: 1. I extract them to a separate file, eg. server_data_mysql.inc.php 2. arrays in config.default.php will become empty (just "array()"). 3. If a non-empty value would appear in config.inc.php, it would overwrite data from new server_data_mysql.inc.php 4. My Drizzle-specific code would go mostly to server_data_drizzle.inc.php
Pros: - after code refactoring and committing 1-3 to master I have to change just one file and make only small adjustments to add Drizzle support, - on average, less code to parse for phpMyAdmin and less data to store in memory because these are used only on three occasions - in db routines, table creation and column editing.
[1] http://repo.or.cz/w/phpmyadmin/crack.git/commit/35843439dfdabd7bb65ebafd2c83...
2011/7/3 Piotr Przybylski piotr.prz@gmail.com:
2011/7/2 Marc Delisle marc@infomarc.info:
Le 2011-07-02 16:09, Piotr Przybylski a écrit :
2011/7/2 Marc Delislemarc@infomarc.info:
Le 2011-07-01 18:57, Piotr Przybylski a écrit :
On a related topic - do we need these to be configurable in config.inc.php? I think these could be moved to a separate file (eg. libraries/mysql.data.php), along with everything that is in config.default.php under "MySQL settings" comment. I see no reason anybody would want to change these, unless you desperately need a user defined function available in phpMyAdmin interface.
Piotr, is this a problem to leave them configurable? Some users or providers probably changed the configuration since it is configurable.
No, I will just have to do a bit more work to filter this for Drizzle :)
I was just wondering, because the only use case I can think of is to add custom native functions.
It can be also to remove unused functions in order to shorten the lists.
By the way, my assumption about the need of some for leaving it configurable is just an assumption.
I suggest asking about this on the phpmyadmin-users list.
Adding Drizzle functions look messy [1] and I am not satisfied with how this turned out. Here's an idea I would like to try, which would make it cleaner while still leaving these arrays configurable the same way as they are now:
- I extract them to a separate file, eg. server_data_mysql.inc.php
- arrays in config.default.php will become empty (just "array()").
- If a non-empty value would appear in config.inc.php, it would
overwrite data from new server_data_mysql.inc.php 4. My Drizzle-specific code would go mostly to server_data_drizzle.inc.php
Pros:
- after code refactoring and committing 1-3 to master I have to change
just one file and make only small adjustments to add Drizzle support,
- on average, less code to parse for phpMyAdmin and less data to store
in memory because these are used only on three occasions - in db routines, table creation and column editing.
So, if I get this right, you will create two sets of arrays, one set for MySQL and one set for Drizzle, which both go into a seperate include file. Where the file that gets included depends on the database server type.
Kind regards,
Dieter
2011/7/3 Dieter Adriaenssens dieter.adriaenssens@gmail.com:
2011/7/3 Piotr Przybylski piotr.prz@gmail.com:
2011/7/2 Marc Delisle marc@infomarc.info:
Le 2011-07-02 16:09, Piotr Przybylski a écrit :
2011/7/2 Marc Delislemarc@infomarc.info:
Le 2011-07-01 18:57, Piotr Przybylski a écrit :
On a related topic - do we need these to be configurable in config.inc.php? I think these could be moved to a separate file (eg. libraries/mysql.data.php), along with everything that is in config.default.php under "MySQL settings" comment. I see no reason anybody would want to change these, unless you desperately need a user defined function available in phpMyAdmin interface.
Piotr, is this a problem to leave them configurable? Some users or providers probably changed the configuration since it is configurable.
No, I will just have to do a bit more work to filter this for Drizzle :)
I was just wondering, because the only use case I can think of is to add custom native functions.
It can be also to remove unused functions in order to shorten the lists.
By the way, my assumption about the need of some for leaving it configurable is just an assumption.
I suggest asking about this on the phpmyadmin-users list.
Adding Drizzle functions look messy [1] and I am not satisfied with how this turned out. Here's an idea I would like to try, which would make it cleaner while still leaving these arrays configurable the same way as they are now:
- I extract them to a separate file, eg. server_data_mysql.inc.php
- arrays in config.default.php will become empty (just "array()").
- If a non-empty value would appear in config.inc.php, it would
overwrite data from new server_data_mysql.inc.php 4. My Drizzle-specific code would go mostly to server_data_drizzle.inc.php
Pros:
- after code refactoring and committing 1-3 to master I have to change
just one file and make only small adjustments to add Drizzle support,
- on average, less code to parse for phpMyAdmin and less data to store
in memory because these are used only on three occasions - in db routines, table creation and column editing.
So, if I get this right, you will create two sets of arrays, one set for MySQL and one set for Drizzle, which both go into a seperate include file. Where the file that gets included depends on the database server type.
Yes. And users will still be able to overwrite this in config.inc.php. An added perk will be that at the point this file is processed we have access to database server version, so we will be able to add TO_SECONDS and UUID_SHORT for newer MySQL versions.
Le 2011-07-03 07:52, Piotr Przybylski a écrit :
2011/7/3 Dieter Adriaenssens dieter.adriaenssens@gmail.com:
2011/7/3 Piotr Przybylski piotr.prz@gmail.com:
2011/7/2 Marc Delisle marc@infomarc.info:
Le 2011-07-02 16:09, Piotr Przybylski a écrit :
2011/7/2 Marc Delislemarc@infomarc.info:
Le 2011-07-01 18:57, Piotr Przybylski a écrit : > On a related topic - do we need these to be configurable in > config.inc.php? I think these could be moved to a separate file (eg. > libraries/mysql.data.php), along with everything that is in > config.default.php under "MySQL settings" comment. I see no reason > anybody would want to change these, unless you desperately need a user > defined function available in phpMyAdmin interface. >
Piotr, is this a problem to leave them configurable? Some users or providers probably changed the configuration since it is configurable.
No, I will just have to do a bit more work to filter this for Drizzle :)
I was just wondering, because the only use case I can think of is to add custom native functions.
It can be also to remove unused functions in order to shorten the lists.
By the way, my assumption about the need of some for leaving it configurable is just an assumption.
I suggest asking about this on the phpmyadmin-users list.
Adding Drizzle functions look messy [1] and I am not satisfied with how this turned out. Here's an idea I would like to try, which would make it cleaner while still leaving these arrays configurable the same way as they are now:
- I extract them to a separate file, eg. server_data_mysql.inc.php
- arrays in config.default.php will become empty (just "array()").
- If a non-empty value would appear in config.inc.php, it would
overwrite data from new server_data_mysql.inc.php 4. My Drizzle-specific code would go mostly to server_data_drizzle.inc.php
Pros:
- after code refactoring and committing 1-3 to master I have to change
just one file and make only small adjustments to add Drizzle support,
- on average, less code to parse for phpMyAdmin and less data to store
in memory because these are used only on three occasions - in db routines, table creation and column editing.
So, if I get this right, you will create two sets of arrays, one set for MySQL and one set for Drizzle, which both go into a seperate include file. Where the file that gets included depends on the database server type.
Yes. And users will still be able to overwrite this in config.inc.php. An added perk will be that at the point this file is processed we have access to database server version, so we will be able to add TO_SECONDS and UUID_SHORT for newer MySQL versions.
Looks like a perfect solution!
2011/7/3 Piotr Przybylski piotr.prz@gmail.com:
2011/7/3 Dieter Adriaenssens dieter.adriaenssens@gmail.com:
2011/7/3 Piotr Przybylski piotr.prz@gmail.com:
2011/7/2 Marc Delisle marc@infomarc.info:
Le 2011-07-02 16:09, Piotr Przybylski a écrit :
2011/7/2 Marc Delislemarc@infomarc.info:
Le 2011-07-01 18:57, Piotr Przybylski a écrit : > On a related topic - do we need these to be configurable in > config.inc.php? I think these could be moved to a separate file (eg. > libraries/mysql.data.php), along with everything that is in > config.default.php under "MySQL settings" comment. I see no reason > anybody would want to change these, unless you desperately need a user > defined function available in phpMyAdmin interface. >
Piotr, is this a problem to leave them configurable? Some users or providers probably changed the configuration since it is configurable.
No, I will just have to do a bit more work to filter this for Drizzle :)
I was just wondering, because the only use case I can think of is to add custom native functions.
It can be also to remove unused functions in order to shorten the lists.
By the way, my assumption about the need of some for leaving it configurable is just an assumption.
I suggest asking about this on the phpmyadmin-users list.
Adding Drizzle functions look messy [1] and I am not satisfied with how this turned out. Here's an idea I would like to try, which would make it cleaner while still leaving these arrays configurable the same way as they are now:
- I extract them to a separate file, eg. server_data_mysql.inc.php
- arrays in config.default.php will become empty (just "array()").
- If a non-empty value would appear in config.inc.php, it would
overwrite data from new server_data_mysql.inc.php 4. My Drizzle-specific code would go mostly to server_data_drizzle.inc.php
Pros:
- after code refactoring and committing 1-3 to master I have to change
just one file and make only small adjustments to add Drizzle support,
- on average, less code to parse for phpMyAdmin and less data to store
in memory because these are used only on three occasions - in db routines, table creation and column editing.
So, if I get this right, you will create two sets of arrays, one set for MySQL and one set for Drizzle, which both go into a seperate include file. Where the file that gets included depends on the database server type.
Yes. And users will still be able to overwrite this in config.inc.php. An added perk will be that at the point this file is processed we have access to database server version, so we will be able to add TO_SECONDS and UUID_SHORT for newer MySQL versions.
But this also means that two lists of functions/... need to be maintained? Or is there a way of getting a list of functions that is available on the database-server (like what you did to get the functions of the Drizzle plugins)?
2011/7/4 Dieter Adriaenssens dieter.adriaenssens@gmail.com:
2011/7/3 Piotr Przybylski piotr.prz@gmail.com:
2011/7/3 Dieter Adriaenssens dieter.adriaenssens@gmail.com:
2011/7/3 Piotr Przybylski piotr.prz@gmail.com:
2011/7/2 Marc Delisle marc@infomarc.info:
Le 2011-07-02 16:09, Piotr Przybylski a écrit :
2011/7/2 Marc Delislemarc@infomarc.info: > Le 2011-07-01 18:57, Piotr Przybylski a écrit : >> On a related topic - do we need these to be configurable in >> config.inc.php? I think these could be moved to a separate file (eg. >> libraries/mysql.data.php), along with everything that is in >> config.default.php under "MySQL settings" comment. I see no reason >> anybody would want to change these, unless you desperately need a user >> defined function available in phpMyAdmin interface. >> > > Piotr, > is this a problem to leave them configurable? Some users or providers > probably changed the configuration since it is configurable. >
No, I will just have to do a bit more work to filter this for Drizzle :)
I was just wondering, because the only use case I can think of is to add custom native functions.
It can be also to remove unused functions in order to shorten the lists.
By the way, my assumption about the need of some for leaving it configurable is just an assumption.
I suggest asking about this on the phpmyadmin-users list.
Adding Drizzle functions look messy [1] and I am not satisfied with how this turned out. Here's an idea I would like to try, which would make it cleaner while still leaving these arrays configurable the same way as they are now:
- I extract them to a separate file, eg. server_data_mysql.inc.php
- arrays in config.default.php will become empty (just "array()").
- If a non-empty value would appear in config.inc.php, it would
overwrite data from new server_data_mysql.inc.php 4. My Drizzle-specific code would go mostly to server_data_drizzle.inc.php
Pros:
- after code refactoring and committing 1-3 to master I have to change
just one file and make only small adjustments to add Drizzle support,
- on average, less code to parse for phpMyAdmin and less data to store
in memory because these are used only on three occasions - in db routines, table creation and column editing.
So, if I get this right, you will create two sets of arrays, one set for MySQL and one set for Drizzle, which both go into a seperate include file. Where the file that gets included depends on the database server type.
Yes. And users will still be able to overwrite this in config.inc.php. An added perk will be that at the point this file is processed we have access to database server version, so we will be able to add TO_SECONDS and UUID_SHORT for newer MySQL versions.
But this also means that two lists of functions/... need to be maintained?
Two similar lists instead of one big for MySQL and two lists of differences to Drizzle (for new and removed functions), which is IMO better - we get two readable arrays and can always do a nice visual diff to look for differences between them.
Or is there a way of getting a list of functions that is available on the database-server (like what you did to get the functions of the Drizzle plugins)?
Most functions are there, but some are missing. I am guessing that standard ANSI SQL functions are just built-in. Second problem - 'Functions' array should contain only functions taking none or one argument which is string or can be transparently converted to correct type by MySQL server, and there is no way to get that information that I know of.
Hi,
One more question - do we need $cfg['*Operators'] variables to be in config files at all? While someone may want to change available functions, I see no reason to change any of these operators as they're part of MySQL's SQL dialect.
Le 2011-07-05 18:25, Piotr Przybylski a écrit :
Hi,
One more question - do we need $cfg['*Operators'] variables to be in config files at all? While someone may want to change available functions, I see no reason to change any of these operators as they're part of MySQL's SQL dialect.
Good point.
2011/7/6 Marc Delisle marc@infomarc.info:
Le 2011-07-05 18:25, Piotr Przybylski a écrit :
Hi,
One more question - do we need $cfg['*Operators'] variables to be in config files at all? While someone may want to change available functions, I see no reason to change any of these operators as they're part of MySQL's SQL dialect.
Good point.
Removed from master.
-
Dieter Adriaenssens -
Marc Delisle -
Piotr Przybylski