Support index acess for Row Type
See original GitHub issueToday we only support access by field for Row Type. For row types without field types, we have to first cast it into a Row with field names:
presto > select CAST(v AS ROW(f1 BIGINT, f2 VARCHAR)).f1
from (VALUES ROW(ROW(1, 'a')), ROW(ROW(2, 'b'))) AS t(v);
_col0
-------
1
2
(2 rows)
It will be nice to support index access, i.e. v[1]
will return the first field of the row.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:3
- Comments:10 (9 by maintainers)
Top Results From Across the Web
Create and use an index to improve performance
You can use an index to help Access find and sort records faster. ... In the Index Name column, in the first blank...
Read more >15: 11.9. Index-Only Scans and Covering Indexes - PostgreSQL
The index type must support index-only scans. B-tree indexes always do. · The query must reference only columns stored in the index. For...
Read more >Array Indexing - MATLAB & Simulink - MathWorks
Access elements of an array by specifying their indices or by checking whether elements meet a condition.
Read more >CREATE INDEX
... access to rows. Oracle Database supports several types of index: Normal indexes. (By default, Oracle Database creates B-tree indexes.) Bitmap indexes ......
Read more >INDEX - Google Docs Editors Help
reference - The range of cells from which the values are returned. row - [OPTIONAL - 0 by default] - The index of...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Index access seems strange given that it must be constant. It’s really a tuple, not an array. What about generating well-known synthetic field names? For example, f1, f2, or c1, c2, etc. This makes it obvious they are constant field accesses and not array accesses.
Good idea! But I think we should only allow constant index, otherwise it will be hard to infer the field type.