Re: pgindent vs. git whitespace check

2023-03-30 Thread Bruce Momjian
On Wed, Mar 29, 2023 at 08:26:23PM +0200, Daniel Gustafsson wrote: > > On 29 Mar 2023, at 19:18, Bruce Momjian wrote: > > We would have to convert all supported branches, and tell all forks to > > do the same (hopefully at the same time). The new standard would then > > be for all single-line

Re: pgindent vs. git whitespace check

2023-03-29 Thread Daniel Gustafsson
> On 29 Mar 2023, at 19:18, Bruce Momjian wrote: > On Thu, Feb 23, 2023 at 09:36:00AM +0100, Daniel Gustafsson wrote: >>> On 23 Feb 2023, at 05:48, Tom Lane wrote: >>> Mass conversion of /* to // style would answer that, >>> but would also create an impossible back-patching problem. >> >>

Re: pgindent vs. git whitespace check

2023-03-29 Thread Bruce Momjian
On Thu, Feb 23, 2023 at 09:36:00AM +0100, Daniel Gustafsson wrote: > > On 23 Feb 2023, at 05:48, Tom Lane wrote: > > > For my own taste, I really don't have any objection to // in isolation -- > > the problem with it is just that we've got megabytes of code in the other > > style. I fear it'd

Re: pgindent vs. git whitespace check

2023-02-24 Thread Peter Eisentraut
On 22.02.23 15:49, Alvaro Herrera wrote: On 2023-Feb-22, Peter Eisentraut wrote: In the meantime, I suggest we work around this, perhaps by conn = libpqsrv_connect_params(keywords, values, /* expand_dbname = */ false, PG_WAIT_EXTENSION); I

Re: pgindent vs. git whitespace check

2023-02-23 Thread Andrew Dunstan
On 2023-02-22 We 23:48, Tom Lane wrote: For my own taste, I really don't have any objection to // in isolation -- the problem with it is just that we've got megabytes of code in the other style. I fear it'd look really ugly to have an intermixture of // and /* comment styles. Maybe, I've

Re: pgindent vs. git whitespace check

2023-02-23 Thread Daniel Gustafsson
> On 23 Feb 2023, at 05:48, Tom Lane wrote: > For my own taste, I really don't have any objection to // in isolation -- > the problem with it is just that we've got megabytes of code in the other > style. I fear it'd look really ugly to have an intermixture of // and /* > comment styles. We

Re: pgindent vs. git whitespace check

2023-02-22 Thread Tom Lane
John Naylor writes: > On Thu, Feb 23, 2023 at 5:03 AM Andrew Dunstan wrote: >> I suspect not allowing // is at least a minor annoyance to any new >> developer we acquire under the age of about 40. > pgindent changes those to our style, so it's not much of an annoyance if > one prefers to type

Re: pgindent vs. git whitespace check

2023-02-22 Thread John Naylor
On Thu, Feb 23, 2023 at 5:03 AM Andrew Dunstan wrote: > > I suspect not allowing // is at least a minor annoyance to any new developer we acquire under the age of about 40. pgindent changes those to our style, so it's not much of an annoyance if one prefers to type it that way during

Re: pgindent vs. git whitespace check

2023-02-22 Thread Andrew Dunstan
On 2023-02-22 We 09:52, Tom Lane wrote: pgindent has never been very kind to non-end-of-line comments, and I'm not excited about working on making it do so. As a thought experiment, what would happen if we reversed course and started allowing "//" comments? Naive conversion of this comment

Re: pgindent vs. git whitespace check

2023-02-22 Thread Tom Lane
Peter Eisentraut writes: > Commit e4602483e95 accidentally introduced a situation where pgindent > disagrees with the git whitespace check. The code is > conn = libpqsrv_connect_params(keywords, values, > /* expand_dbname = */ false, >

Re: pgindent vs. git whitespace check

2023-02-22 Thread Alvaro Herrera
On 2023-Feb-22, Peter Eisentraut wrote: > In the meantime, I suggest we work around this, perhaps by > > conn = libpqsrv_connect_params(keywords, values, /* expand_dbname = > */ false, >PG_WAIT_EXTENSION); I suggest conn =

pgindent vs. git whitespace check

2023-02-22 Thread Peter Eisentraut
Commit e4602483e95 accidentally introduced a situation where pgindent disagrees with the git whitespace check. The code is conn = libpqsrv_connect_params(keywords, values, /* expand_dbname = */ false,