From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me> |
Subject: | Re: Preliminary results for proposed new pgindent implementation |
Date: | 2017-05-19 12:20:22 |
Message-ID: | CA+TgmoamXhAoKY+pPSfGiu=3q6u-+1EOksdPimGS8YuqNuaSYQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 18, 2017 at 11:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> * Improvements in formatting around sizeof and related constructs,
> for example:
>
> * Likewise, operators after casts work better than before:
>
> * Sane formatting of function typedefs, for example:
>
> * Non-typedef struct pointers are now formatted consistently, for example:
>
> * Better handling of pointers with const/volatile qualifiers, for example:
>
> * Better handling of PG_USED_FOR_ASSERTS_ONLY declarations, for example
>
> * Corner cases where no space was left before a comment are fixed:
Those all sound like good things.
> Another set of changes is slightly different handling of unrecognized
> typedef names:
>
> @@ -250,7 +250,7 @@ typedef enum
> PGSS_TRACK_NONE, /* track no statements */
> PGSS_TRACK_TOP, /* only top level statements */
> PGSS_TRACK_ALL /* all statements, including nested ones */
> -} PGSSTrackLevel;
> +} PGSSTrackLevel;
>
> The reason PGSSTrackLevel is "unrecognized" is that it's not in
> typedefs.list, which is a deficiency in our typedef-collection
> technology not in indent. (I believe the problem is that there
> are no variables declared with that typename, causing there to
> not be any of the kind of symbol table entries we are looking for.)
> The handling of such names was already slightly wonky, though;
> note that the previous version was already differently indented
> from what would happen if PGSSTrackLevel were known.
This, however, doesn't sound so good. Isn't there some way this can be fixed?
> All in all, this looks pretty darn good from here, and I'm thinking
> we should push forward on it.
What does that exactly mean concretely?
We've talked about pulling pgindent into our main repo, or posting a
link to a tarball someplace. An intermediate plan might be to give it
its own repo, but on git.postgresql.org, which seems like it might
give us the best of both worlds. But I really want something that's
going to be easy to set up and configure. It took me years to be
brave enough to get the current pgindent set up.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-05-19 12:28:06 | Re: [POC] Faster processing at Gather node |
Previous Message | Tels | 2017-05-19 11:59:44 | Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur |