为什么由VARCHAR2索引的关联数组存储的元素不超过9个

why an Associative array indexed by VARCHAR2 doesn#39;t store more than 9 elements(为什么由VARCHAR2索引的关联数组存储的元素不超过9个)

本文介绍了为什么由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个

基础教程推荐