Re: SQL Code Formatting Patch
От | Dave Page |
---|---|
Тема | Re: SQL Code Formatting Patch |
Дата | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E401388901@ratbert.vale-housing.co.uk обсуждение исходный текст |
Список | pgadmin-hackers |
> -----Original Message----- > From: Edward Di Geronimo Jr. [mailto:edigeronimo@xtracards.com] > Sent: 13 June 2006 17:06 > To: Dave Page > Cc: pgadmin-hackers > Subject: RE: SQL Code Formatting Patch > > 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, Yeuch. > 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. I'll hold off for now - SQL formatting is probably the second most contentious issue in pgAdmin, so we're probably best waiting until everyone's happy. > 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. I generally like my CASE's to be seperated, so let's keep it as is for now. Cheers, Dave.
В списке pgadmin-hackers по дате отправления: