Narrowed the scope of this issue to only the explain statement. Added and documented. We will not create a prepared statement nor cache the results, but otherwise the actual command may execute unmolested.

There really isn't an immediate visual aspect. This is the same plan form you can get over JDBC (either via the old jdbc extension, or with with SET SHOWPLAN etc.). The difference is for pg clients. It's superficially the same syntax as pg and the implementation details of the other methods (only available over jdbc or dependent on the last executed statement, which due to metadata queries may not be the user query) you couldn't really get the query plan from the client.

cool , we need to think some visual aspect to it

Nearly there - https://github.com/teiid/teiid/compare/master...shawkins:TEIID-5740?expand=1

Just need to wire in the final output of the plan with the proxy processor.

It looks like the best option is to emulate pg - at least in terms of the sql EXPLAIN ANALYZE with some of the options supported. We of course will return a different plan document, but in some very basic scenarios there will be support.

I was also considering if adding some kind of plan information through odata makes any scene, but I don't see that it does at this point. There's no high level concept of an odata plan. For the majority of simple reads there is a direct correspondence of odata query to a sql query, but in many instances multiple queries get issued and we have no good way of tying that information together.

On the vdb information we can continue to expand the VIRTUALDATABASE system table for well known properties, but will need to introduce a vdbproperties table or assign some identifier to the vdb itself and reuse the properties table. We'll also want to mimic information_schema representations of grant/role information, but that may need to be spawned as a separate issue.