why an Associative array indexed by VARCHAR2 doesn#39;t store more than 9 elements(为什么由VARCHAR2索引的关联数组存储的元素不超过9个)
问题描述
VARCHAR2(32000)索引的关联数组在下面的代码中仅存储9个元素。 而如果我使用由pls_INTEGER索引的关联数组,我可以在数据结构中存储9个以上的元素(在我的例子中为15个元素)。
那么在我的示例中,为什么使用VARCHAR2索引的关联数组不能接受9个以上的元素。
编码:
declare
--TYPE tabperson IS TABLE OF varchar2(8) INDEX BY pls_integer;
TYPE tabperson IS TABLE OF varchar2(8) INDEX BY varchar2 (32000);
wtabperson tabperson ;
begin
FOR i IN 1..15
LOOP
wtabperson(i) := 'A' || i;
dbms_output.PUT_LINE(
'i---------> ' || 'size ' || wtabperson.last || ' content ' ||
wtabperson(i));
end loop;
end;
这是我在控制台中得到的信息:
[2021-06-14 11:32:59] i---------> size 1 content A1
[2021-06-14 11:32:59] i---------> size 2 content A2
[2021-06-14 11:32:59] i---------> size 3 content A3
[2021-06-14 11:32:59] i---------> size 4 content A4
[2021-06-14 11:32:59] i---------> size 5 content A5
[2021-06-14 11:32:59] i---------> size 6 content A6
[2021-06-14 11:32:59] i---------> size 7 content A7
[2021-06-14 11:32:59] i---------> size 8 content A8
[2021-06-14 11:32:59] i---------> size 9 content A9
[2021-06-14 11:32:59] i---------> size 9 content A10
[2021-06-14 11:32:59] i---------> size 9 content A11
[2021-06-14 11:32:59] i---------> size 9 content A12
[2021-06-14 11:32:59] i---------> size 9 content A13
[2021-06-14 11:32:59] i---------> size 9 content A14
[2021-06-14 11:32:59] i---------> size 9 content A15
那么为什么wtabson.last块位于9。
如果我在示例中使用此类型:
TYPE tabperson IS TABLE OF varchar2(8) INDEX BY pls_integer
我得到了预期的结果:
[2021-06-14 11:39:43] i---------> size 1 content A1
[2021-06-14 11:39:43] i---------> size 2 content A2
//
[2021-06-14 11:39:43] i---------> size 8 content A8
[2021-06-14 11:39:43] i---------> size 9 content A9
[2021-06-14 11:39:43] i---------> size 10 content A10
[2021-06-14 11:39:43] i---------> size 11 content A11
[2021-06-14 11:39:43] i---------> size 12 content A12
[2021-06-14 11:39:43] i---------> size 13 content A13
[2021-06-14 11:39:43] i---------> size 14 content A14
[2021-06-14 11:39:43] i---------> size 15 content A15
有人能解释一下当我使用带有VARCHAR2索引的关联数组时wtabson.last的这种意外行为吗?
提前谢谢
推荐答案
您看到的是,因为索引是一个字符串;您添加的第15个元素的索引为‘15’,而不是数字15;与字符串比较,‘9’高于‘15’。因此,last
显示的字符串值最高,仍为‘9’。如@Koen sais所示,这是the documented behaviour:
对于由PLS_INTEGER索引的关联数组,第一个和最后一个元素分别是具有最小和最大索引的元素。对于按字符串索引的关联数组,第一个和最后一个元素分别是键值最低和最高的元素。
其中‘最高’和‘最低’基于string comparison。
这与有多少元素无关(显然是15个);受影响的只是索引值的行为。
如果您有更多的元素,那么当您传递89时,您将看到last
值发生变化,因为‘90’是比‘9’更高的值,而‘91’是比‘90’更高的值;但是当您传递99时,它会一直保持到900。以此类推。
db<>fiddle
这篇关于为什么由VARCHAR2索引的关联数组存储的元素不超过9个的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:为什么由VARCHAR2索引的关联数组存储的元素不超过9个
基础教程推荐
- 将数据从 MS SQL 迁移到 PostgreSQL? 2022-01-01
- SQL Server:只有 GROUP BY 中的最后一个条目 2021-01-01
- Sql Server 字符串到日期的转换 2021-01-01
- SQL Server 中单行 MERGE/upsert 的语法 2021-01-01
- ERROR 2006 (HY000): MySQL 服务器已经消失 2021-01-01
- 在 VB.NET 中更新 SQL Server DateTime 列 2021-01-01
- 使用pyodbc“不安全"的Python多处理和数据库访问? 2022-01-01
- 如何在 SQL Server 的嵌套过程中处理事务? 2021-01-01
- SQL Server 2016更改对象所有者 2022-01-01
- 无法在 ubuntu 中启动 mysql 服务器 2021-01-01