MySQL Bugs: #36151: Proxy parser.lua -- get_tables function works unexpectedly on subsequent uses

Bug #36151	Proxy parser.lua -- get_tables function works unexpectedly on subsequent uses
Submitted:	16 Apr 2008 19:18
Reporter:	Lachlan Mulcahy	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Proxy: Scripts	Severity:	S3 (Non-critical)
Version:	0.6.1, 0.7.1	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	Contribution

Description:
When using the get_tables function on the parser.lua script bundled with proxy, running the parser more than once gives incorrect/unexpected results.

How to repeat:
Create bugtest.lua:

function read_query ( packet ) 

            local query = "DROP TABLE t"

            local tk = require('proxy.tokenizer')
            local pr = require('proxy.parser')
            local tokens = tk.tokenize(query)

            local tbls = pr.get_tables(tokens)

            for k, v in pairs(tbls) do
                print(k.." => "..v)
            end

            tbls = pr.get_tables(tokens)

            for k, v in pairs(tbls) do
                print(k.." => "..v)
            end

            return proxy.PROXY_SEND_QUERY

end

shell> mysql-proxy --proxy-lua-script=bugtest.lua

Connect to the proxy, issue some query and watch the output.

Suggested fix:
Initialise the ddl_type variable in the get_tables function to avoid subsequent executions using the old value...

Apply this diff to ./lib/proxy/parser.lua:

40a41
>     local ddl_type = nil

This problem seems to persist in version 0.7.1 and trunk, but I'm confused about the output.
Even with the patch there seems to be a problem, but I can't quite figure out what I'm missing off-hand.

Needs test case.

The branch https://code.launchpad.net/~roger-booth/mysql-proxy/laminator has a proposed fix contributed by Roger Booth.
Test case is in progress.

Test the bug with aribtrary queries, without executing them

Attachment: bugtest2.lua (text/x-lua), 868 bytes.

Using the second version of the test script, I ran these queries while connected to the proxy server via the 'test' database.

DROP TABLE t;
UPDATE content SET foo = 'n', id = '2944786' WHERE ( id = '2944786' );
SELECT id from db1.notes;
update db2.notes set message = 'Will it?' where section_id = 61465;
insert into db0.courses (name,instructor) values ('PHY200',1040752);

The DROP TABLE query only prints once, which seems to indicate the initial bug.  However other types of queries don't show this behavior.  There is an additional problem when a write query uses a table in the form 'db.table'.  Both the db and the table are identified as tables.

test.t => write
test.sessions => write
test.db1 => write
test.sessions => write
test.db1 => write
test.content => write
test.content => write
db1.notes => read
db1.notes => read
test.db2 => write
test.notes => write
test.db2 => write
test.notes => write
test.db0 => write
test.db0 => write

Diego Medina writes: 
It was assigned to me by mistake