Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vxjW3-00H5AC-0S for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Mar 2026 10:31:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vxjW1-00CNe5-1q for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Mar 2026 10:31:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vxjW1-00CNdx-0j for pgsql-hackers@lists.postgresql.org; Wed, 04 Mar 2026 10:31:41 +0000 Received: from mail-yw1-x1141.google.com ([2607:f8b0:4864:20::1141]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vxjVy-00000000VsQ-3iaP for pgsql-hackers@lists.postgresql.org; Wed, 04 Mar 2026 10:31:41 +0000 Received: by mail-yw1-x1141.google.com with SMTP id 00721157ae682-78fc4425b6bso65697467b3.1 for ; Wed, 04 Mar 2026 02:31:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772620297; cv=none; d=google.com; s=arc-20240605; b=G9buV1wtQXst2KfPepnDLOPoyCwOw2zHuC0pXrpubWpJaNMnjZJBg1QosVBICvnoSt T1V27oEN3T5iC47KOXkFJk5RfKZAwRAXfwzV+mFVtq5phUs9LSV3uIIYUTguZeccYFFO JntKluS9aieC8okle3+3j5pcPy6UvxFMqzj5Su146vs6oVuQD9Ru6dEPBjMPSZmKBPFI EzHoWweuIrMKiq+XGR5m/QYdlX6/atQzw8pD7QI+/TF/R5yqV2rQ3C+8t5Dx5fBU5iXS 5YnGTr1QzkDx4g51mFfwWCeuBFIilsDXWbiSEHjU2lWiBFA42znznS9V/0CfkKHSc69f 1UFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=oy6qlOFcknn6f+DkUTg1+0uzh/pBE7EiZEMCa49puPg=; fh=h9TBRZaqEnx0RSqxJWbBttXnRBGYP6RVuDpUnNafyNs=; b=cTjwh9MjTZ1CYZD50BNvNLXestKO9HwK6mBraM2gXQksvOGLQVkB9fK6HQHlHuSpwK RJfAUWW5wkv373f9/N6FBelophNC4dWpY71ORnfH9bc+FzQEJwGNwJQuTGlnR4R/aeE6 k08Is5b6ffMKsC0am3hTD9Eat6+c303/xuqytFtKYpdqftzFBprjMMvwLXLXAwxctEPl 0LMGzYbiYKa8KtZsAi0Q6+lsS+Y75mpUp2tR3QrOP1pixOpBfU7H2EpT3V4G0RmzFbTU R9Mhju18YSgOW+lwzvN2xmoWMe+ecyMUC2BuKBg5GkN+uRnokKH15S3n9galkwT1KqAS RArg==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772620297; x=1773225097; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oy6qlOFcknn6f+DkUTg1+0uzh/pBE7EiZEMCa49puPg=; b=lehIP30SjMU+s+DcY4R/2qVAeMusHBdrUndmx/MDMwVhio1ejHbMvGxvEY42fNZXxM /58A9CIA47P/uyVS82Rw0P2YMdE+dsSiESo2TW8zQiB/tt4ZhnhORI9vN8Ti6n3Xj7zM a++WNuvGoY75alhIjd7olJ8JmvdAvBQ5J82ZyS4TwrnTooopmV6KocEZgh/6ZCBlYkTV uf7YMcB6o0q50l52eiYiefVfTUNSx48sq4g+thj2uYbbb23hV0qJzMMzkBfB8hpbA9xM icahsOk4rCXhv1R10xAkzbikZ5sGkiYyZy+mFD5MqszKwSxUdN/gdqrfK/SvPef97qiD EQ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772620297; x=1773225097; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oy6qlOFcknn6f+DkUTg1+0uzh/pBE7EiZEMCa49puPg=; b=ddLihTMVSmN2AHs+MsO7URsRZ+W60htyf9IEJdSgxj/zcBUQKCga5Ts8id0k2UGQ98 mCnmwq/a/IirPoGGJBIrpCMOQLV5Y1T9sfvMbHh6/sbbUoPsU86/weN5Dy65PVg/Rt03 jzF7QLb/5XdNi9LqLcEfd6fD8jk2LhXUcCryuVYNcuW5M7BAuslHLDfDT8q1ZtbP8h0u 9fkqeYmC0d7iUxY/2Q0NJJrm6h56Oc81wqYlEEExZeXyxoBlhC/4pdFO2OtjOjDrGyy4 +h/ASEZmPWfF3Zl7RahPUlTgmGbXDLvnISj1WAuPgv6qEyAGoUPPlDyoYRyu8g82xIN1 3TpA== X-Forwarded-Encrypted: i=1; AJvYcCWmnUoouXrlBjbpHUPbpD0U1iVCf7Ygf4e5zW3qslYdeEUfdj6zRLCRnj+vrXBxijzIs4Weepf6At/heCYy@lists.postgresql.org X-Gm-Message-State: AOJu0Yyd7aIbzOGsmVHOXOCNV8l5P7xd6tT++a2Jg526HqDMeXfKCnv1 bA4+PzBuvFTdZt/OhsAp25YztNBYpmsBg74ZFk3ounSOzO1sp0VWulWJXUSGEBcm48QlNlOj4QL 3sP6EDrfXthYAGSPl+KJbbVIZSt3FY8w= X-Gm-Gg: ATEYQzw5mNvXCaTNc/e/jqyT1HkYufbKJk46IsCUGAK7Jtzh1IWXNRWREtEbjYY7aTd OuCEmWq3+SggD2QfxcYfXZY2woxEcb/gVKgZp82VD17/K/m7USm2Fc9E8WMBYkqcwqepj3GKIa0 3Gm3I7vBYqibJTvgxw7dJ+ydcwW0YsvxOm27gVk+oYFhVQOmQtoUtLTPAMv4O1wp35yUbMuMaZE GtaoiwdsFZaimr5T3Lqp67Tom7PjoaZwqTKghz+8PoCE1ZLoxX6pgifVjOLh4QWmvSguei+ld2e nTVNsh0= X-Received: by 2002:a05:690c:4903:b0:794:9d24:76b0 with SMTP id 00721157ae682-798c6ccbf51mr11214577b3.54.1772620296851; Wed, 04 Mar 2026 02:31:36 -0800 (PST) MIME-Version: 1.0 References: <202602261236.ttanikrvfx6w@alvherre.pgsql> <63229AD5-48DB-417C-9361-EA478DAF57AF@gmail.com> In-Reply-To: From: zhanghu Date: Wed, 4 Mar 2026 18:31:24 +0800 X-Gm-Features: AaiRm50sAgT7KR2XJmdYE5wl9noIb0TMwatV1G_2uoUHj3Tr4yojUNerWR5MAss Message-ID: Subject: Re: guc: make dereference style consistent in check_backtrace_functions To: =?UTF-8?Q?=C3=81lvaro_Herrera?= Cc: Junwang Zhao , pgsql-hackers@lists.postgresql.org, Chao Li Content-Type: multipart/alternative; boundary="0000000000001d93d3064c305379" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001d93d3064c305379 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable zhanghu =E4=BA=8E2026=E5=B9=B43=E6=9C=882=E6=97=A5= =E5=91=A8=E4=B8=80 11:17=E5=86=99=E9=81=93=EF=BC=9A > > zhanghu =E4=BA=8E2026=E5=B9=B42=E6=9C=8827=E6=97= =A5=E5=91=A8=E4=BA=94 16:46=E5=86=99=E9=81=93=EF=BC=9A > > > > > > > > Chao Li =E4=BA=8E2026=E5=B9=B42=E6=9C=8827=E6= =97=A5=E5=91=A8=E4=BA=94 09:34=E5=86=99=E9=81=93=EF=BC=9A > >> > >> > >> > >> > On Feb 26, 2026, at 20:37, =C3=81lvaro Herrera wrote: > >> > > >> > There is at least one more place in the code where this is done. > >> > > >> > >> I did a search with the command: grep -RInE '\*[[:space:]]*[A-Za-z_][A-Za-z0-9_]*\[0\]' src contrib --include=3D'*.c' > >> > >> Excluding irrelevant results, there are 3 more occurrences: > >> > >> 1 - contrib/basic_archive/basic_archive.c line 105 > >> ``` > >> if (*newval =3D=3D NULL || *newval[0] =3D=3D '\0') > >> return true; > >> ``` > >> > >> Here, the code checks *newval first, which implies that the subsequent *newval[0] is unintentional syntax. > >> > >> 2 - src/interfaces/ecpg/pgtypeslib/interval.c line 62 > >> ``` > >> int > >> DecodeInterval(char **field, int *ftype, int nf, /* int range, */ > >> int *dtype, struct /* pg_ */ tm *tm, fsec_t *fsec) > >> { > >> ... > >> if (IntervalStyle =3D=3D INTSTYLE_SQL_STANDARD && *field[0] = =3D=3D '-') > >> { > >> /* Check for additional explicit signs */ > >> bool more_signs =3D false; > >> > >> for (i =3D 1; i < nf; i++) > >> { > >> if (*field[i] =3D=3D '-' || *field[i] =3D=3D '= +') > >> { > >> more_signs =3D true; > >> break; > >> } > >> } > >> ``` > >> > >> 3 - src/backend/utils/adt/datatime.c line 3522 > >> ``` > >> int > >> DecodeInterval(char **field, int *ftype, int nf, int range, > >> int *dtype, struct pg_itm_in *itm_in) > >> { > >> ... > >> if (IntervalStyle =3D=3D INTSTYLE_SQL_STANDARD && nf > 0 && *field[0] =3D=3D '-') > >> { > >> force_negative =3D true; > >> /* Check for additional explicit signs */ > >> for (i =3D 1; i < nf; i++) > >> { > >> if (*field[i] =3D=3D '-' || *field[i] =3D=3D '= +') > >> { > >> force_negative =3D false; > >> break; > >> } > >> } > >> } > >> ``` > >> > >> Where 2&3 makes this patch more interesting. > >> > >> Both occurrences are inside functions named DecodeInterval. For non-zero i, the code also performs *field[i]: > >> > >> Given this code has been there for years, I don=E2=80=99t believe it i= s a bug. I checked the callers of DecodeInterval in both files and found that field is defined as: > >> ``` > >> char *field[MAXDATEFIELDS]; > >> ``` > >> > >> This explains why *field[i] works; it is doing the intended thing by getting the first character of the string at array position i. > >> > >> However, since the precedence between the [] and * operators frequently confuses people, I suggest adding parentheses to make the intention explicit as *(field[i]). Furthermore, I think we should change the function signatures to use the type char *field[] to reflect the actual type the functions expect. If a caller were to pass a true char ** typed field to DecodeInterval, the current logic would result in a bug. > >> > >> See the attached diff for my suggested changes. > >> > >> Best regards, > >> -- > >> Chao Li (Evan) > >> HighGo Software Co., Ltd. > >> https://www.highgo.com/ > >> > >> Hi, > >> > >> Thank you all for the reviews and detailed feedback. > >> > >> =C3=81lvaro, thanks for pointing out that there were additional > >> occurrences elsewhere in the tree. I have updated the original > >> patch to address those cases; the revised version is attached > >> as v2-0001. > >> > >> I also appreciate the review and suggestions from > >> Chao and Junwang. > >> > >> Regarding the additional changes suggested by Chao: they go > >> somewhat beyond the original scope of my original patch. > >> To keep the discussion concrete, I have included Chao=E2=80=99s propos= ed > >> diff as a separate patch (v2-0002) so it can be reviewed independently= . > >> > >> I have reviewed v2-0002 locally, and it looks good to me. > >> > >> Thanks again for the guidance. > >> > >> Regards, > >> Zhang Hu > >> > >> > > Hi, > > I am planning to add this patch to the current CommitFest, but when > logging in to commitfest.postgresql.org I get the message: > > =E2=80=9CYou have not passed the cool off period yet.=E2=80=9D > > It seems my account is still within the cool-off period after registration. > > Could someone please add this patch to the CommitFest on my behalf? > > Thanks. > > Best regards, > Zhang Hu Hi =C3=81lvaro, Thank you for pointing that out. I have fixed the additional occurrence you mentioned and updated the patch accordingly. I have also added the patch to the CommitFest: https://commitfest.postgresql.org/patch/6566/ Please let me know if there is anything else I should do for this patch. Thanks for your help. Best regards, Zhang Hu --0000000000001d93d3064c305379 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


zhanghu <kongbaik228@gmail.com> =E4=BA=8E2026=E5=B9=B43=E6=9C=882=E6=97=A5= =E5=91=A8=E4=B8=80 11:17=E5=86=99=E9=81=93=EF=BC=9A
>
> zhanghu= <kongbaik228@gmail.com>= =E4=BA=8E2026=E5=B9=B42=E6=9C=8827=E6=97=A5=E5=91=A8=E4=BA=94 16:46=E5=86= =99=E9=81=93=EF=BC=9A
> >
> >
> >
> > C= hao Li <li.evan.chao@gmail.com= > =E4=BA=8E2026=E5=B9=B42=E6=9C=8827=E6=97=A5=E5=91=A8=E4=BA=94 09:3= 4=E5=86=99=E9=81=93=EF=BC=9A
> >>
> >>
> >= >
> >> > On Feb 26, 2026, at 20:37, =C3=81lvaro Herrera &= lt;alvherre@kurilemu.de> wro= te:
> >> >
> >> > There is at least one more = place in the code where this is done.
> >> >
> >>= ;
> >> I did a search with the command: grep -RInE '\*[[:sp= ace:]]*[A-Za-z_][A-Za-z0-9_]*\[0\]' src contrib --include=3D'*.c= 9;
> >>
> >> Excluding irrelevant results, there ar= e 3 more occurrences:
> >>
> >> 1 - contrib/basic_a= rchive/basic_archive.c line 105
> >> ```
> >> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 if (*newval =3D=3D NULL || *newval[0] =3D=3D '= \0')
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 return true;
> >> ```
> >>
> >> = Here, the code checks *newval first, which implies that the subsequent *new= val[0] is unintentional syntax.
> >>
> >> 2 - src/i= nterfaces/ecpg/pgtypeslib/interval.c line 62
> >> ```
> &= gt;> int
> >> DecodeInterval(char **field, int *ftype, int n= f, =C2=A0 =C2=A0 =C2=A0 =C2=A0/* int range, */
> >> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0int *dtype, struct /* pg_ */ tm *tm, fsec_t *fsec)
> >= ;> {
> >> =C2=A0 ...
> >> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 if (IntervalStyle =3D=3D INTSTYLE_SQL_STANDARD && *field[0] = =3D=3D '-')
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> = >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Check f= or additional explicit signs */
> >> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bool =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0more_signs =3D false;
> >>
> >> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for (i =3D 1; i < nf; i++)
= > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
= > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 if (*field[i] =3D=3D '-' || *field[i] =3D= =3D '+')
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> >> =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 more_signs =3D true;
> >> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> >> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> &g= t;> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> &g= t;> ```
> >>
> >> 3 - src/backend/utils/adt/data= time.c line 3522
> >> ```
> >> int
> >>= DecodeInterval(char **field, int *ftype, int nf, int range,
> >&g= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0int *dtype, struct pg_itm_in *itm_in)
> &g= t;> {
> >> =C2=A0...
> >> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 if (IntervalStyle =3D=3D INTSTYLE_SQL_STANDARD && nf > 0 = && *field[0] =3D=3D '-')
> >> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 {
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 force_negative =3D true;
> >> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Check for additional explicit signs *= /
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = for (i =3D 1; i < nf; i++)
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*field[i] =3D= =3D '-' || *field[i] =3D=3D '+')
> >> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 {
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 force_negative = =3D false;
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 }
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 }
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 }> >> ```
> >>
> >> Where 2&3 makes t= his patch more interesting.
> >>
> >> Both occurren= ces are inside functions named DecodeInterval. For non-zero i, the code als= o performs *field[i]:
> >>
> >> Given this code has= been there for years, I don=E2=80=99t believe it is a bug. I checked the c= allers of DecodeInterval in both files and found that field is defined as:<= br>> >> ```
> >> =C2=A0 =C2=A0 char *field[MAXDATEFIEL= DS];
> >> ```
> >>
> >> This explains w= hy *field[i] works; it is doing the intended thing by getting the first cha= racter of the string at array position i.
> >>
> >>= However, since the precedence between the [] and * operators frequently co= nfuses people, I suggest adding parentheses to make the intention explicit = as *(field[i]). Furthermore, I think we should change the function signatur= es to use the type char *field[] to reflect the actual type the functions e= xpect. If a caller were to pass a true char ** typed field to DecodeInterva= l, the current logic would result in a bug.
> >>
> >&g= t; See the attached diff for my suggested changes.
> >>
>= >> Best regards,
> >> --
> >> Chao Li (Evan)=
> >> HighGo Software Co., Ltd.
> >> https://www.highgo.com/
> >>
> = >> Hi,
> >>
> >> Thank you all for the review= s and detailed feedback.
> >>
> >> =C3=81lvaro, tha= nks for pointing out that there were additional
> >> occurrence= s elsewhere in the tree. I have updated the original
> >> patch= to address those cases; the revised version is attached
> >> a= s v2-0001.
> >>
> >> I also appreciate the =C2=A0re= view and suggestions from
> >> Chao and Junwang.
> >&g= t;
> >> Regarding the additional changes suggested by Chao: the= y go
> >> somewhat beyond the original scope of my original pat= ch.
> >> To keep the discussion concrete, I have included Chao= =E2=80=99s proposed
> >> diff as a separate patch (v2-0002) so = it can be reviewed independently.
> >>
> >> I have = reviewed v2-0002 locally, and it looks good to me.
> >>
>= >> Thanks again for the guidance.
> >>
> >> = Regards,
> >> Zhang Hu
> >>
> >>
>= ;
> Hi,
>
> I am planning to add this patch to the curren= t CommitFest, but when
> logging in to commitfest.postgresql.org I get the message:
>
= > =E2=80=9CYou have not passed the cool off period yet.=E2=80=9D
>=
> It seems my account is still within the cool-off period after regi= stration.
>
> Could someone please add this patch to the Commit= Fest on my behalf?
>
> Thanks.
>
> Best regards,> Zhang Hu

Hi =C3=81lvaro,

Thank you for pointing that out.

I have fixed the additional occurrence you mention= ed and updated the patch accordingly. I have also added the patch to the Co= mmitFest:

https://commitfest.postgresql.org/patch/6566/<= /a>

Please let me know if there is anyt= hing else I should do for this patch.

T= hanks for your help.

Best regards,
Zhang Hu

--0000000000001d93d3064c305379--