If I need to generate 3 rows called AAA, BBB, CCC, I could use dual and union all. Another method is to use Extensibility Types
select * from table
(sys.ODCIVarchar2List('AAA','BBB','CCC'));
COLUMN_VALUE
------------
AAA
BBB
CCC
If I need to generate 3 rows called AAA, BBB, CCC, I could use dual and union all. Another method is to use Extensibility Types
select * from table
(sys.ODCIVarchar2List('AAA','BBB','CCC'));
COLUMN_VALUE
------------
AAA
BBB
CCC
Nice trick.
I’ve used the following, which is also available in 9iR2:
select * from table(sys.dbms_debug_vc2coll(‘A’,'B’,'C’));
This one is a TABLE OF VARCHAR2(1000), where ODCIVarchar2List is a VARRAY(32767) OF VARCHAR2(4000), so yours does give more space.
Come on, it takes a single SQL to create your own defined types. Why rely on system types that may change in the next release? One less thing to check for upgrade.
DJ,
Why should a SQL statement depend on a type, when there is a documented datatype which is not supposed to change in next release (because it is documented). Oracle cannot remove features in a next release without notice. I would say it is OK to rely on them because *they are documented*
Those extensibility types also exist for date, numbers and raw.
Gary,
How could you say my one use more space? 32767 is a limit. Also varchar2(1000) is a meaningless constraint on varchar2, 4000 is the maximum. Could you show the difference in memory usage?
But true, those extensibility types are documented only in 10gR2 and 11gR1. So in 9iR2, dbms_debug_vc2coll sounds possible
I made a test Garry and it seems you are right about memory usage.
What imho really sucks is that oracle is not capable of producing a set of reusable components for pl/sql development. E.g., there should be a goddamn standard table of varchar2(4000) that everybody uses! Well, they’d better get a better name
Some ODCI varrays existed in 9i, like ODCINUMBERLIST. However, I found them documented only in 10gR2
Nice trick , thanks…