Can you supply an example on what is bad and how it should look like?

I think that results should be exposed as a tabular results (like we have in view queries of Hibernate Statistics).
Currently the results are exposed in one field (I think that's is a render bug and not the intend)
See the screenshot for further details.

this should be an enhancement request. This isn't a bug per-se - the data is there, just not in a format the reporter would like.

I think this operation could be enhanced by providing a new, required, parameter - "max rows" (because otherwise, a select * could concievably blow up the rhq_config_props table with milliions of rows fo data). We could then make the results a list of maps (where each map consists of a row of data - each key in the map representing a column).

Perfectly, I agree with you.
I was thinking that's a render bug because the results are formated as a html table, but don't showed as a html table.
Now, I now that's an intend.

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1615
Imported an attachment (id=368590)

(In reply to John Mazzitelli from comment #3)
> I think this operation could be enhanced by providing a new, required,
> parameter - "max rows" (because otherwise, a select * could concievably blow
> up the rhq_config_props table with milliions of rows fo data). We could then

Right, good idea.

> make the results a list of maps (where each map consists of a row of data -
> each key in the map representing a column).

Is that really possible? How would you configure the plugin descriptor, if you don't know the list of column in advance?

(In reply to Thomas Segismont from comment #6)
> > make the results a list of maps (where each map consists of a row of data -
> > each key in the map representing a column).
> 
> Is that really possible? How would you configure the plugin descriptor, if
> you don't know the list of column in advance?

I was probably thinking that this operation wasn't a generic SQL select - if you had specific queries that are to be wrapped as operations, you would know what columns the queries returned and you could use list-o-maps. But in the case of a generic SQL operation, yes, you are right - unless you know the columns being returned, you'll have to do something else. Perhaps a single column in the descriptor to represent a row?

      <operation name="viewGenericSQLSelectResults" description="View a SQL SELECT query results">
         <results>
            <c:list-property name="rows">
               <c:map-property name="row">
                  <c:simple-property name="rownumber" summary="true"/>
                  <c:simple-property name="data" summary="true"/>
               </c:map-property>
            </c:list-property>
         </results>
      </operation>

Or, if you want to avoid having a row number column, I think you can just use a list:

      <operation name="viewGenericSQLSelectResults" description="View a SQL SELECT query results">
         <results>
            <c:list-property name="rows" />
         </results>
      </operation>

Those are just some ideas.

Fixed in master

commit fb9f14d0fcd552b72d7347521e252b68daf167b2
Author: Thomas Segismont <tsegismo>
Date:   Wed Jul 9 16:59:41 2014 +0200

Introduced a new "outputFormat" paramater for the "invokeSql" operation. Values may be "formattedText" or "html". Defaults to html (which was the only supported format before).
    
Formatted text prints tables like this (select id, uuid from rhq_resource limit 3) :
    
++++++++++++++++++++++++++++++++++++++++++++++++++++
+ id (int4) +            uuid (bpchar)             +
++++++++++++++++++++++++++++++++++++++++++++++++++++
+     10018 + eba7a118-4b46-4166-b391-7977b28e5f25 +
+     10722 + 94068e4c-1929-490c-ac8e-9d51a1a9f29c +
+     10002 + d2dbdbcb-d070-4682-b05a-2383f5d3395a +
++++++++++++++++++++++++++++++++++++++++++++++++++++

Bulk close of items fixed in RHQ 4.12

If you think this is not solved, then please open a *new* BZ and link to this one.