| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, ranier_gyn(at)hotmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: [BUG FIX] Uninitialized var fargtypes used. | 
| Date: | 2019-11-12 20:10:46 | 
| Message-ID: | 20191112201046.GA29021@alvherre.pgsql | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
On 2019-Nov-12, Tom Lane wrote:
> If we're going to revert 0a52d378b03b we should just treat the
> problem straightforwardly.  I was imagining
> 
> -        if (memcmp(argtypes, clist->args, nargs * sizeof(Oid)) == 0)
> +        /* if nargs==0, argtypes can be null; don't pass that to memcmp */
> +        if (nargs == 0 ||
> +            memcmp(argtypes, clist->args, nargs * sizeof(Oid)) == 0)
> 
> It's really stretching credulity to imagine that one more test-and-branch
> in this loop costs anything worth noticing, especially compared to the
> costs of having built the list to begin with.  So I'm now feeling that
> 0a52d378b03b was penny-wise and pound-foolish.
I pushed using that approach.
For a minute I thought that it should also test that clist->nargs also
equals 0, but that turns out not to be necessary since the number of
arguments is already considered by FuncnameGetCandidates above.
Thanks
-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2019-11-12 20:34:35 | BUG #16109: Postgres planning time is high across version - 10.6 vs 10.10 | 
| Previous Message | Juan José Santamaría Flecha | 2019-11-12 18:59:35 | Re: BUG #16108: Colorization to the output of command-line has unproperly behaviors at Windows platform |