Merge pull request #3283 from EnterpriseDB/docs/epas_editng_1019

basic spl elements content

product_docs/docs/epas/14/epas_compat_cat_views/index.mdx

@@ -1,6 +1,6 @@
 ---
 navTitle: Catalog Views
-title: "Database compatibility for Oracle developers catalog views"
+title: "Database compatibility for Oracle developers: catalog views"
 ---
 
 Catalog views provide information about database objects. There are two catagories of catalog views:

product_docs/docs/epas/14/epas_compat_spl/01_basic_spl_elements/02_case_sensitivity.mdx

@@ -4,15 +4,17 @@ title: "Case sensitivity"
 
 <div id="case_sensitivity" class="registered_link"></div>
 
-Keywords and user-defined identifiers that are used in an SPL program are case insensitive. So for example, the statement `DBMS_OUTPUT.PUT_LINE('Hello World');` is interpreted to mean the same thing as `dbms_output.put_line('Hello World');` or `Dbms_Output.Put_Line('Hello World');` or `DBMS_output.Put_line('Hello World');`.
+Keywords and user-defined identifiers that are used in an SPL program are case insensitive. For example, the statement `DBMS_OUTPUT.PUT_LINE('Hello World');` is interpreted the as `dbms_output.put_line('Hello World');` or `Dbms_Output.Put_Line('Hello World');` or `DBMS_output.Put_line('Hello World');`.
 
-Character and string constants, however, are case sensitive as well as any data retrieved from the EDB Postgres Advanced Server database or data obtained from other external sources. The statement `DBMS_OUTPUT.PUT_LINE('Hello World!');` produces the following output:
+Character and string constants, however, are case sensitive. Data retrieved from the EDB Postgres Advanced Server database or from other external sources is also case sensitive. 
+
+The statement `DBMS_OUTPUT.PUT_LINE('Hello World!');` produces the following output:
 
 ```text
 Hello World!
 ```
 
-However the statement `DBMS_OUTPUT.PUT_LINE('HELLO WORLD!');` produces the output:
+The statement `DBMS_OUTPUT.PUT_LINE('HELLO WORLD!');` produces this output:
 
 ```text
 HELLO WORLD!

product_docs/docs/epas/14/epas_compat_spl/01_basic_spl_elements/03_identifiers.mdx

@@ -4,9 +4,9 @@ title: "Identifiers"
 
 <div id="identifiers" class="registered_link"></div>
 
-*Identifiers* are user-defined names that are used to identify various elements of an SPL program including variables, cursors, labels, programs, and parameters. The syntax rules for valid identifiers are the same as for identifiers in the SQL language.
+*Identifiers* are user-defined names that identify elements of an SPL program including variables, cursors, labels, programs, and parameters. The syntax rules for valid identifiers are the same as for identifiers in the SQL language.
 
-An identifier must not be the same as an SPL keyword or a keyword of the SQL language. The following are some examples of valid identifiers:
+An identifier can't be the same as an SPL keyword or a keyword of the SQL language. The following are some examples of valid identifiers:
 
 ```text
 x

product_docs/docs/epas/14/epas_compat_spl/01_basic_spl_elements/04_qualifiers.mdx

@@ -4,30 +4,39 @@ title: "Qualifiers"
 
 <div id="qualifiers" class="registered_link"></div>
 
-A *qualifier* is a name that specifies the owner or context of an entity that is the object of the qualification. A qualified object is specified as the qualifier name followed by a dot with no intervening white space, followed by the name of the object being qualified with no intervening white space. This syntax is called *dot notation*.
+A *qualifier* is a name that specifies the owner or context of an entity that's the object of the qualifier. Specify a qualified object using these elements, in order:
+
+1. The qualifier name 
+2. A dot with no intervening white space
+3. The name of the object being qualified with no intervening white space
+
+This syntax is called *dot notation*.
 
 The following is the syntax of a qualified object.
 
 ```text
 <qualifier>. [ <qualifier>. ]... <object>
 ```
 
-`qualifier` is the name of the owner of the object. `object` is the name of the entity belonging to `qualifier`. It is possible to have a chain of qualifications where the preceding qualifier owns the entity identified by the subsequent qualifier(s) and object.
+`qualifier` is the name of the owner of the object. `object` is the name of the entity belonging to `qualifier`. You can have a chain of qualifications in which the preceding qualifier owns the entity identified by the subsequent qualifiers and object.
 
-Almost any identifier can be qualified. What an identifier is qualified by depends upon what the identifier represents and the context of its usage.
+You can qualify almost any identifier. How you qualify an identifier depends on what the identifier represents and its context.
 
 Some examples of qualification follow:
 
--   Procedure and function names qualified by the schema to which they belong - e.g., `schema_name.procedure_name(...)`
--   Trigger names qualified by the schema to which they belong - e.g., `schema_name.trigger_name`
--   Column names qualified by the table to which they belong - e.g., `emp.empno`
--   Table names qualified by the schema to which they belong - e.g., `public.emp`
--   Column names qualified by table and schema - e.g., `public.emp.empno`
+-   Procedure and function names qualified by the schema to which they belong, e.g., `schema_name.procedure_name(...)`
+-   Trigger names qualified by the schema to which they belong, e.g., `schema_name.trigger_name`
+-   Column names qualified by the table to which they belong, e.g., `emp.empno`
+-   Table names qualified by the schema to which they belong, e.g., `public.emp`
+-   Column names qualified by table and schema, e.g., `public.emp.empno`
+
+As a general rule, where a name appears in the syntax of an SPL statement you can use its qualified name as well. Typically, a qualified name is used only if ambiguity is associated with the name. Examples of ambiguity include, for example:
 
-As a general rule, wherever a name appears in the syntax of an SPL statement, its qualified name can be used as well. Typically a qualified name would only be used if there is some ambiguity associated with the name. For example, if two procedures with the same name belonging to two different schemas are invoked from within a program or if the same name is used for a table column and SPL variable within the same program.
+-  Two procedures with the same name belonging to two different schemas are invoked from a program.
+-  The same name is used for a table column and SPL variable in the same program.
 
-You should avoid using qualified names if at all possible. In this chapter, the following conventions are adopted to avoid naming conflicts:
+Avoid using qualified names if possible. We use the following conventions to avoid naming conflicts:
 
--   All variables declared in the declaration section of an SPL program are prefixed by `v_`. E.g., `v_empno`
--   All formal parameters declared in a procedure or function definition are prefixed by `p_`. E.g., `p_empno`
--   Column names and table names don't have any special prefix conventions. E.g., column `empno` in table `emp`
+-   All variables declared in the declaration section of an SPL program are prefixed by `v_`, e.g., `v_empno`.
+-   All formal parameters declared in a procedure or function definition are prefixed by `p_`, e.g., `p_empno`.
+-   Column names and table names don't have any special prefix conventions, e.g., column `empno` in table `emp`.

product_docs/docs/epas/14/epas_compat_spl/01_basic_spl_elements/05_constants.mdx

@@ -7,8 +7,8 @@ legacyRedirectsGenerated:
 
 <div id="constants" class="registered_link"></div>
 
-*Constants* or *literals* are fixed values that can be used in SPL programs to represent values of various types - e.g., numbers, strings, dates, etc. Constants come in the following types:
+*Constants* or *literals* are fixed values that you can use in SPL programs to represent values of various types such as numbers, strings, and dates. Constants come in the following types:
 
--   Numeric (Integer and Real)
--   Character and String
+-   Numeric (integer and real)
+-   Character and string
 -   Date/time

product_docs/docs/epas/14/epas_compat_spl/01_basic_spl_elements/06_user_defined_pl_sql_subtypes.mdx

@@ -8,9 +8,9 @@ legacyRedirectsGenerated:
 
 <div id="user_defined_pl_sql_subtypes" class="registered_link"></div>
 
-EDB Postgres Advanced Server supports user-defined PL/SQL subtypes and (subtype) aliases. A subtype is a data type with an optional set of constraints that restrict the values that can be stored in a column of that type. The rules that apply to the type on which the subtype is based are still enforced, but you can use additional constraints to place limits on the precision or scale of values stored in the type.
+EDB Postgres Advanced Server supports user-defined PL/SQL subtypes and subtype aliases. A subtype is a data type with an optional set of constraints that restrict the values that can be stored in a column of that type. The rules that apply to the type on which the subtype is based are still enforced, but you can use additional constraints to place limits on the precision or scale of values stored in the type.
 
-You can define a subtype in the declaration of a PL function, procedure, anonymous block or package. The syntax is:
+You can define a subtype in the declaration of a PL function, procedure, anonymous block, or package. The syntax is:
 
 ```text
 SUBTYPE <subtype_name> IS <type_name>[(<constraint>)] [NOT NULL]
@@ -22,17 +22,15 @@ Where `constraint` is:
 {<precision> [, <scale>]} | <length>
 ```
 
-Where:
-
 `subtype_name`
 
  `subtype_name` specifies the name of the subtype.
 
 `type_name`
 
- `type_name` specifies the name of the original type on which the subtype is based. `type_name` may be:
+ `type_name` specifies the name of the original type on which the subtype is based. `type_name` can be:
 
--   The name of any of the type supported by EDB Postgres Advanced Server.
+-   The name of any of the types supported by EDB Postgres Advanced Server.
 -   The name of any composite type.
 -   A column anchored by a `%TYPE` operator.
 -   The name of another subtype.
@@ -49,51 +47,51 @@ Include the `constraint` clause to define restrictions for types that support pr
 
 `length`
 
- `length` specifies the total length permitted in a value of `CHARACTER, VARCHAR`, or `TEXT` base types.
+ `length` specifies the total length permitted in a value of `CHARACTER`, `VARCHAR`, or `TEXT` base types.
 
-Include the `NOT NULL` clause to specify that `NULL` values may not be stored in a column of the specified subtype.
+Include the `NOT NULL` clause to specify that you can't store `NULL` values in a column of the specified subtype.
 
-A subtype that is based on a column inherits the column size constraints, but the subtype doesnt inherit `NOT NULL` or `CHECK` constraints.
+A subtype that is based on a column inherits the column size constraints, but the subtype doesn't inherit `NOT NULL` or `CHECK` constraints.
 
 ## Unconstrained subtypes
 
-To create an unconstrained subtype, use the `SUBTYPE` command to specify the new subtype name and the name of the type on which the subtype is based. For example, the following command creates a subtype named `address` that has all of the attributes of the type, `CHAR:`
+To create an unconstrained subtype, use the `SUBTYPE` command to specify the new subtype name and the name of the type on which the subtype is based. For example, the following command creates a subtype named `address` that has all of the attributes of the type `CHAR`:
 
 ```
 SUBTYPE address IS CHAR;
 ```
 
-You can also create a subtype (constrained or unconstrained) that is a subtype of another subtype:
+You can also create a subtype (constrained or unconstrained) that's a subtype of another subtype:
 
 ```
 SUBTYPE cust_address IS address NOT NULL;
 ```
 
-This command creates a subtype named `cust_address` that shares all of the attributes of the `address` subtype. Include the `NOT NULL` clause to specify that a value of the `cust_address` may not be `NULL`.
+This command creates a subtype named `cust_address` that shares all of the attributes of the `address` subtype. Include the `NOT NULL` clause to specify that a value of the `cust_address` can't be `NULL`.
 
 ## Constrained subtypes
 
-Include a `length` value when creating a subtype that is based on a character type to define the maximum length of the subtype. For example:
+Include a `length` value when creating a subtype that's based on a character type to define the maximum length of the subtype. For example:
 
 ```
 SUBTYPE acct_name IS VARCHAR (15);
 ```
 
-This example creates a subtype named `acct_name` that is based on a `VARCHAR` data type, but is limited to 15 characters in length.
+This example creates a subtype named `acct_name` that's based on a `VARCHAR` data type but is limited to 15 characters.
 
-Include values for `precision` (to specify the maximum number of digits in a value of the subtype) and optionally, `scale` (to specify the number of digits to the right of the decimal point) when constraining a numeric base type. For example:
+Include values for `precision` to specify the maximum number of digits in a value of the subtype. Optionally, include values for `scale` to specify the number of digits to the right of the decimal point when constraining a numeric base type. For example:
 
 ```
 SUBTYPE acct_balance IS NUMBER (5, 2);
 ```
 
-This example creates a subtype named `acct_balance` that shares all of the attributes of a `NUMBER` type, but that may not exceed 3 digits to the left of the decimal point and 2 digits to the right of the decimal.
+This example creates a subtype named `acct_balance` that shares all of the attributes of a `NUMBER` type but that can't exceed three digits to the left of the decimal point and two digits to the right of the decimal.
 
-An argument declaration (in a function or procedure header) is a *formal* *argument*. The value passed to a function or procedure is an *actual* *argument*. When invoking a function or procedure, the caller provides (0 or more) actual arguments. Each actual argument is assigned to a formal argument that holds the value within the body of the function or procedure.
+An argument declaration (in a function or procedure header) is a *formal argument*. The value passed to a function or procedure is an *actual argument*. When invoking a function or procedure, the caller provides 0 or more actual arguments. Each actual argument is assigned to a formal argument that holds the value in the body of the function or procedure.
 
 If a formal argument is declared as a constrained subtype:
 
--   EDB Postgres Advanced Server does not enforce subtype constraints when assigning an actual argument to a formal argument when invoking a function.
+-   EDB Postgres Advanced Server doesn't enforce subtype constraints when assigning an actual argument to a formal argument when invoking a function.
 -   EDB Postgres Advanced Server enforces subtype constraints when assigning an actual argument to a formal argument when invoking a procedure.
 
 ## Using the %TYPE operator
@@ -104,10 +102,10 @@ You can use `%TYPE` notation to declare a subtype anchored to a column. For exam
 SUBTYPE emp_type IS emp.empno%TYPE
 ```
 
-This command creates a subtype named `emp_type` whose base type matches the type of the `empno` column in the `emp` table. A subtype that's based on a column shares the column size constraints; `NOT NULL` and `CHECK` constraints are not inherited.
+This command creates a subtype named `emp_type` whose base type matches the type of the `empno` column in the `emp` table. A subtype that's based on a column shares the column size constraints. `NOT NULL` and `CHECK` constraints aren't inherited.
 
 ## Subtype conversion
 
 Unconstrained subtypes are aliases for the type on which they are based. Any variable of type subtype (unconstrained) is interchangeable with a variable of the base type without conversion, and vice versa.
 
-A variable of a constrained subtype may be interchanged with a variable of the base type without conversion, but a variable of the base type may only be interchanged with a constrained subtype if it complies with the constraints of the subtype. A variable of a constrained subtype may be implicitly converted to another subtype if it is based on the same subtype, and the constraint values are within the values of the subtype to which it is being converted.
+You can interchange a variable of a constrained subtype with a variable of the base type without conversion. However, you can interchange a variable of the base type with a constrained subtype only if it complies with the constraints of the subtype. You can implicitly convert a variable of a constrained subtype to another subtype if it's based on the same subtype and the constraint values are within the values of the subtype to which it is being converted.

product_docs/docs/epas/14/epas_compat_spl/01_basic_spl_elements/07_character.mdx

@@ -4,14 +4,13 @@ title: "Character set"
 
 <div id="character_set" class="registered_link"></div>
 
-SPL programs are written using the following set of characters:
+Write identifiers, expressions, statements, control structures, and so on that comprise the SPL language using the following characters:
 
--   Uppercase letters `A` thru `Z` and lowercase letters `a` thru `z`
--   Digits `0` thru `9`
--   Symbols `( ) + - * / < > = ! ~ ^ ; : . ' @ % , " # $ & _ | { } ? [ ]`
--   White space characters tabs, spaces, and carriage returns
+-   Uppercase letters A&ndash;Z and lowercase letters a&ndash;z
+-   Digits 0&ndash;9`
+-   Symbols ( ) + - * / < > = ! ~ ^ ; : . ' @ % , " # $ & _ | { } ? [ ]
+-   Whitespace characters tab, space, and carriage return
 
-Identifiers, expressions, statements, control structures, etc. that comprise the SPL language are written using these characters.
 
 !!! Note
     The data that can be manipulated by an SPL program is determined by the character set supported by the database encoding.

product_docs/docs/epas/14/epas_compat_spl/01_basic_spl_elements/index.mdx

@@ -8,4 +8,4 @@ legacyRedirectsGenerated:
 
 <div id="basic_spl_elements" class="registered_link"></div>
 
-This section discusses the basic programming elements of an SPL program.
+The basic programming elements of an SPL program include aspects such as as case sensitivity and the available character set.