Quoting Dave Page <[email protected]>:

I would expect the subselects to look more like:

        (
              SELECT ((((h2.hd_hardware_id::text || ' ('::character
varying::text) || a2.gbl_name::text) || ',
                          '::character varying::text) ||
h2.hd_model::text) || ')'::character varying::text
                FROM hd_hardware h2,
                     gbl_addr_book a2
               WHERE h2.hd_manufacturer = a2.gbl_guid
                     AND h2.hd_guid = sr_header.sr_hardware_id
         ) AS hardware,

Having the braces in non-matched positions decreases the readability I
think. Thoughts?

I agree that it would be better as you wrote, and that was my original intention, but I'm having trouble pulling that off without side effects that make things look much worse. I've got a version that handles the parens around the select ok, but, has issues with the other parens in that example. The above would come out something like this:

        (
SELECT ((((h2.hd_hardware_id::text || ' ('::character varying::text
             ) || a2.gbl_name::text
             ) || ',                          '::character varying::text
             ) || h2.hd_model::text
             ) || ')'::character varying::text
                FROM hd_hardware h2,
                     gbl_addr_book a2
               WHERE h2.hd_manufacturer = a2.gbl_guid
                     AND h2.hd_guid = sr_header.sr_hardware_id
         ) AS hardware,

I'll look at it a little more, but I don't have high hopes of getting it better without making the scanner try to understand the SQL instead of the current approach of just reacting to things of interest. I do have an idea that may work, but I'm not sure yet. It'll take a while for me to work out, and I'm not sure how quickly I'll be able to get to it, so you may want to go ahead with the current patch for now.

BTW, there's a table of keywords in the code that defines what should be done when they're detected. There's a bool at the end that determines if a new line should be inserted before the keyword. You may want to change that to false for the CASE keyword. I wasn't sure if there were instances where that would backfire, so I figured extra newlines were better than not enough of them. My main concern is if you try using case somewhere in the where clause.

Ed

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to