Re: Autoformatting

Hello!

Attached are current designs for SQL autoformatting. This feature is not
developed yet, only mockups of a potential solution so technical
implementation is still being discussed. Style guide for autoformatting
doesn't yet exist either, what's shown is manually formatted by another
person.

When a user highlights a section of text, a menu option appears below with
the option to autoformat text.

Not included in this current design:
- other options available when highlighting multiple sections of text
- compacting queries

We're currently testing this design with pgAdmin3 users. Looking to
validate with a few more before developing the feature. Let us know your
thoughts!

*1. Query pasted into text editor*
[image: 16- unformatted query.png]

*2. Query highlighted and autoformat option appears*
[image: 17- query highlighted.png]

*3. Query formatted*
[image: 18- formatted query.png]
On Wed, Feb 15, 2017 at 9:40 AM Raffi Holzer <rholzer(at)pivotal(dot)io> wrote:

> Thanks Dave! We came to the same conclusion about a button press. And
> thank you for the SQL guidelines.
>
> On Wed, Feb 15, 2017 at 4:37 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
> Hi
>
> On Tue, Feb 14, 2017 at 3:02 PM, Raffi Holzer <rholzer(at)pivotal(dot)io> wrote:
> > Hi Dave,
> > When we were talking about auto formatting we were actually referring
> to a
> > single button press doing all of these things to a large block of text.
> The
> > use case here would be if you receive a large illegible query and paste
> it
> > into the query editor it would either automatically auto-format or you
> would
> > press a button and it would auto-format.
>
> Oh, OK.
>
> > We are trying to determine a few
> > things. One, are there preferred formatting guidelines
>
> Hmm, it seems I missed SQL when I wrote our (basic) coding standards:
> https://www.pgadmin.org/docs4/1.x/coding_standards.html
>
> By default (in my opinion), we should have 4 character indents, new
> lines for logically distinct objects (e.g. columns or constraints on a
> table), commas etc. at the end of the line, keywords in upper case,
> e.g.
>
> SELECT
> a,
> b,
> FROM
> t
> ORDER BY
> a,
> b;
>
> However, that obviously becomes unwieldy in some cases, so common
> sense is needed:
>
> SELECT
> a, b,
> FROM
> t
> ORDER BY
> a, b;
>
> There should of course be a limit on the number of columns listed per
> line - but should the limit be a count or max width in chars? With a
> CREATE TABLE statement I think it's clear that each column should be
> on it's own line:
>
> CREATE TABLE t (
> a serial NOT NULL PRIMARY KEY,
> b text
> );
>
> In other words, we need to define (or adopt) a formal standard for
> this, and then write a parser/formatter - which seems like a decidedly
> non-trivial amount of work (FYI, I tried the Python format-sql module,
> and it failed on ~80% of my tests - probably either because it doesn't
> understand COPY or pl/pgsql).
>
> > and two, how should
> > this autoformatting be implemented? On a button press? Upon pasting in
> the
> > text?
>
> Definitely not on pasting - if you drop in a large script, it could
> take far too long, plus you may not care, or be looking at the
> original source in another tool and trying to mentally reconcile lines
> or statements to each other. I would say it should be a
> button/shortcut.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>
>
> --
> Raffi Holzer
> Product Manager
> Pivotal Labs
>