Skip site navigation (1) Skip section navigation (2)

Re: SQL Code Formatting Patch

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Edward Di Geronimo Jr(dot)" <edigeronimo(at)xtracards(dot)com>
Cc: "pgadmin-hackers" <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: SQL Code Formatting Patch
Date: 2006-06-13 20:00:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers

> -----Original Message-----
> From: Edward Di Geronimo Jr. [mailto:edigeronimo(at)xtracards(dot)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,


> 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

Cheers, Dave.

pgadmin-hackers by date

Next:From: svnDate: 2006-06-14 14:22:33
Subject: SVN Commit by dpage: r5227 - in trunk/pgadmin3: . pkg/redhat
Previous:From: Edward Di Geronimo Jr.Date: 2006-06-13 16:05:34
Subject: Re: SQL Code Formatting Patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group