PL/SQL parser
(MDEV-10142)
|
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Parser, Stored routines |
| Affects Version/s: | 10.3 |
| Fix Version/s: | 10.3.0 |
| Type: | Technical task | Priority: | Major |
| Reporter: | Alexander Barkov | Assignee: | Alexander Barkov |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | Compatibility | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Sprint: | 10.2.2-3, 10.2.2-1, 10.2.2-2, 10.2.2-4, 10.1.18 | ||||||||||||||||||||||||
| Description |
|
This task will implement Oracle-stype table%ROWTYPE declarations, for sql_mode=ORACLE. Example:
The record variable rec can store the entire row of the data fetched from the table t1. There is no a need to specify column names and data types. They're automatically copied from t1. Under scope of this task, we'll implement table%ROWTYPE for routine variables. Using table%ROWTYPE for routine parameters and function return values will be done separately. A complete working example:
Data types will be resolved at the very beginning of a routine execution, in sp_rcontext::create(). If the tables referenced in %ROWTYPE declarations are altered inside the routine, this will not affect structures of the referencing %ROWTYPE variables. In the below example the variable rec will have only two fields a and b, it will not have the field c. The fact that rec is declared after the ALTER statement does not matter. This implementations will be close to Oracle, who determines all data types at CREATE PROCEDURE time. table%ROWTYPE and implicit ROW variables will be mutually assignable if they have the same number of fields. Note, Oracle has stricter rules, it also checks field names, but in a very strange way. See "Oracle implementation details". We won't check field names. Assignment will be done from left to right (the N'th source field is assigned to the N'th destination field). In the below example all three variables rec0, rec1, rec2 will be mutually assignable, because they have the same number of fields:
It will be possible to pass a table%ROWTYPE variable into a routine with a compatible explicit ROW argument:
|
| Comments |
| Comment by Alexander Barkov [ 2017-02-27 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
Oracle implementation detailsFETCH assigns fields of table%ROWTYPE variables from left to right. Field names are not important.
Two table%ROWTYPE variables are mutually assignable if they have the same set of equally named fields, but the order of the fields is not important. Strangely, fields are assigned by their ordinal position, from left to right:
| |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alexander Barkov [ 2017-03-10 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Pushed to bb-10.2-compatibility | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michael Widenius [ 2017-03-11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Review not done | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Michael Widenius [ 2017-03-11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Review done, some minor changes needed + some function comments | |||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alexander Barkov [ 2017-04-04 ] | |||||||||||||||||||||||||||||||||||||||||||||||||
|
Addressed Monty's review suggestions. |