Dropping into k can be useful to see the representation.
Tab is
+`time`col1`col2!(times;(`col11`col12!1 3;`col11`col12!5 33);(`col11`col12!1 3;`col11`col12!5 33))
What’s interesting is that
exec col1 from tab
then produces
(`col11`col12!1 3;`col11`col12!5 33)
But pasting this into the repl gives back a table,
+`col11`col12!(1 5;3 33)
So it seems like there’s some automatic table conversion that’s not happening in exec, that does happen in other cases. Interesting! Not much of an answer, but might help to find one.
q collapses dictionaries with matching keys into a table. However this doesn’t happen if the list in question is a table column.
The pretty printing logic still does the conversion as part of printing the value, but doesn’t change the underlying type, which means functions that expect a “real” table will fail.
You can force the collapsing by remaking the list using an each:
q)type(::)each exec col1 from tab 98h q)cols(::)each exec col1 from tab `col11`col12
It’s a property of some operations and not others. exec just picks the column out of the table without walking through it. The equivalent operation is tab[;col1]</span>. However <span style="font-family: "courier;">tab[col1] is an odd operation because normally the first index to a table is the row and not the column, which implies that q must do something extra under the hood to come up with the same result as tab[;`col1], which includes rebuilding the column.
Similarly if you include a trivial condition in the exec such as exec col1 from tab where 1b then it acts the same as just exec col1 from tab . However if you add a nontrivial condition, even if it’s always true, such as exec col1 from tab where 0<=i then suddenly q has to walk through the column to build the answer which means it will be collapsed. Try different operations with t to see the difference in the time they take (I tried with 10000 rows and t:1000 to get a measurable result).
tab.col1 is another equivalent to tab[;col1]</span> (besides the limitations that it can't be used everywhere). It's <span style="font-family: "courier;">tabcol1 that is the odd one out since it breaks the usual rules for indexing.