2015-01-29 11:57 GMT-02:00 Tom Worster <fsb@thefsb.org>:

Hi Oleksandr,

I'm going to stop bitching about Maria now. My needs are in fact met by
the current dyncol functions:

- It's not so hard to write methods that generate CREATE_COLUMN()
expressions from a general data structure.

- COLUMN_JSON() is just fine for all my reading purposes. I see no need
for a naked COLUMN_GET() in a SELECT.

take care, when you return more data than you really need, you use more network, memory, cpu, cache, buffers...

something like SELECT * FROM table, when you only need SELECT column_a FROM table

with big system or small hardware you may have problems

- Generating COLUMN_GET() expressions for use in queries ends up being a
regex replace with some packaging.

take care with the size of final query... for example

SELECT COLUMN_GET(),COLUMN_GET(),COLUMN_GET()..... 256 times FROM table

if your network is a problem, maybe is better SELECT column FROM table, and execute the column_get at client side, this reduce network, and memory used at client and server side with the SQL string (query)

- As I said in the email to Frederico this morning, indexes are not
unimportant but a lot of apps can live without and many will be fine.

When I wrote my original email, that list of seven concerns were factors
in my vague worry that dyncols are going to remain ignored and unloved.

i like and use them =] but i don't love dynamic column without index, today i execute workarounds to solve this

That original email is adequately answered and I have the information I
need.

nice =]

Tom