Re: [HACKERS] Preliminary results for proposed new pgindentimplementation
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Preliminary results for proposed new pgindentimplementation |
Дата | |
Msg-id | 20170519163008.6algqcf66ldu2bxa@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Preliminary results for proposed new pgindent implementation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Preliminary results for proposed new pgindent implementation
|
Список | pgsql-hackers |
On 2017-05-19 12:21:52 -0400, Robert Haas wrote: > On Fri, May 19, 2017 at 11:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I certainly would rather that our version matched something that's under > > active maintenance someplace. But it seems like there are two good > > arguments for having a copy in our tree: > > > > * easy accessibility for PG developers > > > > * at any given time we need to be using a specific "blessed" version, > > so that all developers can get equivalent results. There's pretty much > > no chance of that happening if we depend on distro-provided packages, > > even if those share a common upstream. > > Yeah, but those advantages could also be gained by putting the > pgindent tree on git.postgresql.org in a separate repository. Having > it in the same repository as the actual PostgreSQL code is not > required nor, in my opinion, particularly desirable. I'm of the contrary opinion. A lot of the regular churn due to pgindent right now is because it's inconvenient to run. Having to clone a separate repository, compile that project, put it into PATH (fun if there's multiple versions), run pgindent, discover typedefs.list is out of date, update, run, ... is pretty much a guarantee that'll continue. If we had a make indent that computed local typedefs list, *added* new but not removed old ones, we could get much closer to just always being properly indented. The cost of putting it somewhere blow src/tools/pgindent seems fairly minor. - Andres
В списке pgsql-hackers по дате отправления: