Mysql – How to get Super Priviledge for a database on an online server

You can try to change log_bin_trust_function_creators; however, there is an alternative approach that seems more appropriate when you consider the meaning of that variable:

It controls whether stored function creators can be trusted not to create stored functions that will cause unsafe events to be written to the binary log.

A setting of 0 also enforces the restriction that a function must be declared with the DETERMINISTIC characteristic, or with the READS SQL DATA or NO SQL characteristic. If the variable is set to 1, MySQL does not enforce these restrictions on stored function creation.

All that option does is assume that you know what you are doing, without making you assert that you do by using one of the three characteristics in your CREATE statement... but if you don't properly declare the function, you may miss out on potential optimizations.

misdeclaring a routine might affect results or affect performance

Taken together, this implies that the most correct approach is to declare your stored functions with DETERMINISTIC or READS SQL DATA or NO SQL as appropriate, and, if these do not correctly describe your function's behavior, then your function still may result in unsafe statements being written to the binary log, because these options are also "trusted:"

Assessment of the nature of a routine is based on the “honesty” of the creator: MySQL does not check that a routine declared DETERMINISTIC is free of statements that produce nondeterministic results.

Curious aside: astute observers will note that I omitted something from the documentation's description:

If set to 0 (the default), users are not permitted to create or alter stored functions unless they have the SUPER privilege in addition to the CREATE ROUTINE or ALTER ROUTINE privilege.

Since nobody gets SUPER in RDS, and assuming this is not an error in the official documentation, this seems like it must be an AWS customization of MySQL behavior.

Thanks to the OP's clarification of the error, I'm going to post my comment as a suggested answer.

In SQL Server, permissions are checked only when ownership changes.

Consider the following tables:

• Table SchemaA.Table1, owned by Alice.
• View SchemaA.View1, owned by Alice, depends on Schema1.Table1.
• View SchemaB.View1, owned by Bob, depends on Schema1.View1.

Consider these situations:

1. Alice attempts to select from SchemaA.Table1:

   No change in ownership so permissions are not checked on the table. Alice is allowed access.

2. Alice attempts to select from SchemaA.View1:

   No change in ownership so permissions are not checked on the view or on the table. Alice is allowed access.

3. Bob attempts to select from SchemaA.Table1:

   There is a change in ownership on SchemaA.Table1 (Bob is attempting an operation on Alice's object) so Bob's permissions are checked on SchemaA.Table1.

4. Bob attempts to select from SchemaA.View1:

   This is a change in ownership on SchemaA.View1 (Bob is attempting an operation on Alice's object) so Bob's permissions are checked on SchemaA.View1. There is no change in ownership from SchemaA.View1 to SchemaA.Table1 so Bob's permissions are not checked on SchemaA.Table1.

5. Bob attempts to select from SchemaB.View1.

   There is no change in ownership on SchemaB.View1 (Bob is attempting an operation on Bob's object) so permissions are not checked on SchemaB.View1. There is a change in ownership from SchemaB.View1 to SchemaA.View1 so Bob's permissions (not Alice's) are checked on SchemaA.View1. There is no change in ownership from SchemaA.View1 to SchemaA.Table1 so Bob's permissions are not checked on SchemaA.Table1.

So, in the OP's sitation, the view [TESTCTRL].[CTRL_TEST_VIEW] depends upon the table [TESTDATA].[UserData]. The view and the table have different owners so there is a change in ownership (something some SQL Server books call a "break in the ownership chain"). To query the view, JoeUser needs to be granted the appropriate permissions to both the view and the table.