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,
PG_WAIT
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 lo
> 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.
>>
>> Yeah,
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 com
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 = libpqsrv_conne
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,
>
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 cou
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 development.
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 it
> 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 c
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 see
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 su
12 matches
Mail list logo