Value.getType() is not reliable for CLASS_REREF

[Mike McMahon]

It always returns java.lang.Object.class and not the type of the referenced object.

It is a little tricky to get reference equal Objects into a Value in the server. First because the normal persistent format is RowData and second because parsed / computed objects tend to be only equals(). However, Sort_Tree uses Values and system tables have some constant string values and some functions return a string rather than computing it.

So the following will show the problem:

SELECT character_set_schema, collation_schema FROM information_schema.tables ORDER BY table_id;

SELECT s1, s2 FROM (SELECT id, CURRENT_USER AS s1, CURRENT_USER AS s2 FROM t2 LIMIT 5) AS x ORDER BY 1;

It is not just strings. This would, too, except for other bugs that happen first:

SELECT d1, d2 FROM (SELECT id, CAST(1 AS DECIMAL(2,1)) AS d1, CAST(1 AS DECIMAL(2,1)) AS d2 FROM t2 LIMIT 5) AS x ORDER BY 1;

[Yuval Shavit (yshavit)]

I'm creating a workaround for now in the server; see lp:~yshavit/akiban-server/t3_PKPVS-workaround.

[Yuval Shavit (yshavit)]

Whoops, same mistake twice. Renaming to t3_PVPVS-workaround

[Yuval Shavit (yshavit)]

The server workaround comes with a TODO to clean it up when this bug is fixed: https://www.pivotaltracker.com/story/show/38746213

[Yuval Shavit (yshavit)]

This can also result in value.isNull() returning false, value.getType() returning Object.class, and value.get() returning null. DumpClientTest in lp:akiban-client-tools triggers this.

[Nathan Williams (nwilliams)]

Mark as fixed in Persistit, but adding affects Server so the cleanup can still be tracked.

[Yuval Shavit (yshavit)]

Cleanup is in.