Merge remote-tracking branch 'upstream/develop' into CUBRIDMAN-114_1

en/install.rst

@@ -164,7 +164,7 @@ When rpm is executed, CUBRID is installed in the "cubrid" home directory (/opt/c
 
     $ cubrid service start
 
-.. note:: \
+.. note::
 
     *   **RPM and dependency**
 

en/sql/authorization.rst

@@ -17,6 +17,10 @@ CUBRID has two types of users by default: **DBA** and **PUBLIC**. At initial ins
 
 *   The **DBA** user has the authorization of the database administrator. The **DBA** automatically becomes the member of all users and groups. That is, the **DBA** is granted the access for all tables. Therefore, there is no need to grant authorization explicitly to the **DBA** and **DBA** members. Each database user has a unique name. The database administrator can create multiple users simultaneously using the **cubrid createdb** utility (see :ref:`cubrid-utilities` for details). A database user cannot have a member who already has the same authorization. If authorization is granted to a user, all members of the user is automatically granted the same authorization.
 
+.. note::
+
+    From version 11.3 of CUBRID, **DBA** members can also query objects of all users in the system catalog virtual class.
+
 .. _create-user:
 
 CREATE USER
@@ -145,7 +149,7 @@ The following example shows how to grant retrieving authorization on the *record
 
     GRANT SELECT ON record, history TO brown WITH GRANT OPTION;
 
-.. note:: \
+.. note::
 
     *   The grantor of authorization must be the owner of all tables listed before the grant operation or have **WITH GRANT OPTION** specified.
     *   Before granting **SELECT**, **UPDATE**, **DELETE** and **INSERT** authorization for a virtual table, the owner of the virtual table must have **SELECT** and **GRANT** authorization for all the tables included in the query specification. The **DBA** user and the members of the **DBA** group are automatically granted all authorization for all tables.

en/sql/i18n.rst

@@ -726,7 +726,7 @@ If not explicitly set otherwise at column creation, the charset and collation of
 The charset and collation are taken (in order in is found first) from the client.
 If the result of an expression is a character data type, gets the collation and charset by the collation inference with the operands of the expression.
 
-.. note:: \
+.. note::
 
     In CUBRID, collations are supported for a number of languages, including European and Asian. In addition to the different alphabets, some of these languages may require the definition of expansions or contractions for some characters or character groups. Most of these aspects have been put together by the Unicode Consortium into The Unicode Standard (up to version 6.1.0 in 2012). Most of the information is stored in the DUCET file `http://www.unicode.org/Public/UCA/latest/allkeys.txt <http://www.unicode.org/Public/UCA/latest/allkeys.txt>`_ which contains all characters required by most languages.
 

en/sql/jsp.rst

@@ -331,17 +331,17 @@ Creating Connection
 ---------------------
 
 To access the database from a Java stored function/procedure, you must use the server-side JDBC driver.
-To acquire a connection to the database using the server-side JDBC driver, you can either use "**jdbc:default:connection:**" as the URL for JDBC connection, or call the **getDefaultConnection** () method of the **cubrid.jdbc.driver.CUBRIDDriver** class.
+To acquire a connection to the database using the server-side JDBC driver, you can use "**jdbc:default:connection:**" as the URL for JDBC connection.
 
 .. code-block:: java
 
     Connection conn = DriverManager.getConnection("jdbc:default:connection:");
 
-or
-
-.. code-block:: java
+.. note::
 
-    Connection conn = cubrid.jdbc.driver.CUBRIDDriver.getDefaultConnection();
+    From the CUBRID 11.2, Acquiring a connection in the following way is no longer supported:
+
+        Connection conn = cubrid.jdbc.driver.CUBRIDDriver.getDefaultConnection();
 
 .. note::
 

en/sql/query/delete.rst

@@ -31,7 +31,7 @@ You can delete records in the table by using the **DELETE** statement. You can s
 
 When a table to delete records is only one, :ref:`limit-clause` can be specified. You can limit the number of records by specifying the :ref:`limit-clause`.  If the number of records satisfying the :ref:`where-clause` exceeds *row_count*, only the number of records specified in *row_count* will be deleted.
 
-.. note:: \
+.. note::
 
     *   On the **DELETE** statement with multiple tables, the table alias can be defined within <*table_specifications*> only. At the outside of <*table_specifications*>, the table alias defined in <*table_specifications*> can be used.
 

en/sql/query/set.rst

@@ -144,7 +144,7 @@ The following example shows how to delete the user-defined variable *a* and *use
     DEALLOCATE VARIABLE @a, @user_defined_variable;
     DROP VARIABLE @a, @user_defined_variable;
 
-.. note:: \
+.. note::
 
     The user-defined variables that are defined by the **SET** statement start by connecting an application to a server and will be maintained until the application terminates the connection. The connection maintained during this period is called a session. When an application terminates the connection or when there are no requests for a certain period of time, the session will expire, and the user-defined variables will be deleted as a result. You can set the session time with the **session_state_timeout** parameter of **cubrid.conf**; the default value is **21600** seconds (=6 hours).
 

en/sql/schema/serial_stmt.rst

@@ -301,6 +301,6 @@ For example, if you create a serial starting 101 and increasing by 1 and call **
 
     120
 
-.. note:: \
+.. note::
 
     If you create a serial and calls the **SERIAL_NEXT_VALUE** function for the first time, a value of (serial interval) * (desired number of serials - 1) added to the current value is returned. If you call the **SERIAL_NEXT_VALUE** function in succession, a value of (serial interval) * (desired number of serials) added to the current is returned (see the example above).

en/sql/transaction.rst

@@ -203,7 +203,7 @@ To set cursor holdability to close the cursor when a transaction is committed, s
 
 The default setting for applications that were developed based on CCI is to hold the cursor. If the cursor is set to 'not to hold a cursor' at connection level and you want to hold the cursor, define the **CCI_PREPARE_HOLDABLE** flag while preparing a query. The default setting for CCI drivers (PHP, PDO, ODBC, OLE DB, ADO.NET, Perl, Python, Ruby) is to hold the cursor. To check whether a driver supports the cursor holdability setting, refer to the **PREPARE** function of the driver.
 
-.. note:: \
+.. note::
 
     * Note that versions lower than CUBRID 9.0 do not support cursor holdability. The default setting of those versions is to close all cursors at commit.
     * CUBRID currently does not support ResultSet.HOLD_CURSORS_OVER_COMMIT in java.sql.XAConnection interface.