Re: [HACKERS] Preliminary results for proposed new pgindent implementation
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Preliminary results for proposed new pgindent implementation |
Дата | |
Msg-id | 26654.1495203668@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Preliminary results for proposed new pgindent implementation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Preliminary results for proposed new pgindentimplementation
(Stephen Frost <sfrost@snowman.net>)
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, May 18, 2017 at 11:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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.) > This, however, doesn't sound so good. Isn't there some way this can be fixed? I'm intending to look into it, but I think it's mostly independent of whether we replace pgindent itself. The existing code has the same problem, really. One brute-force way we could deal with the problem is to have a "manual" list of names to be treated as typedefs, in addition to whatever the buildfarm produces. I see no other way than that to get, for instance, simplehash.h's SH_TYPE to be formatted as a typedef. There are also some typedefs that don't get formatted correctly because they are only used for wonky options that no existing typedef-reporting buildfarm member builds. Manual addition might be the path of least resistance there too. Now the other side of this coin is that, by definition, such typedefs are not getting used in a huge number of places. If we just had to live with it, it might not be awful. >> 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? That means I plan to continue putting effort into it with the goal of making a switchover sometime pretty darn soon. We do not have a very wide window for fooling with pgindent rules, IMO --- once v11 development starts I think we can't touch it again (until this time next year). > 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. Yes, moving the goalposts on ease-of-use is an important consideration here. What that says to me is that we ought to pull FreeBSD indent into our tree, and provide Makefile support that makes it easy for any developer to build it and put it into their PATH. (I suppose that means support in the MSVC scripts too, but somebody else will have to do that part.) We should also think hard about getting rid of the entab dependency, to eliminate the other nonstandard prerequisite program. We could either accept that that will result in some tab-vs-space changes in our code, or try to convert those steps in pgindent into pure Perl, or try to convince Piotr to add an option to indent that will make it do tabs the way we want (ie use a space not a tab if the tab would only move one space anyway). Lastly (and I've said this before, but you pushed back on it at the time), if we're doing this then we're going all in. That means reformatting the back branches to match too. That diff is already big enough to be a disaster for back-patching, and we haven't even considered whether we want to let pgindent adopt less-inconsistent rules for comment indentation. So I think that as soon as the dust has settled in HEAD, we back-patch the addition of FreeBSD indent, and the changes in pgindent proper, and then run pgindent in each supported back branch. regards, tom lane
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Robert HaasДата:
Сообщение: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables
Следующее
От: Pierre-Emmanuel AndréДата:
Сообщение: Re: [HACKERS] PostgreSQL 10beta1 - compilation fails on OpenBSD-current