| From: | Nico Williams <nico(at)cryptonector(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Allowing printf("%m") only where it actually works |
| Date: | 2018-08-19 04:50:50 |
| Message-ID: | 20180819045050.GB16780@localhost |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Aug 18, 2018 at 04:34:50PM -0400, Tom Lane wrote:
> So now I'm about ready to propose that we just *always* use
> snprintf.c, and forget all of the related configure probing.
Yes.
> This'd have some advantages, notably that we'd get the
> useful_strerror() behavior in frontend as well as backend,
> assuming we converted all our frontend code to use %m.
You'd also get to ensure that all uses from *die() are
async-signal-safe.
You'd also ensure that snprintf.c gets maximal testing.
> And we'd not exactly be the first project to decide that.
> But it's kind of a big move from where we are today.
>
> Thoughts?
I think that is the best approach.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-08-19 05:15:58 | Re: Allowing printf("%m") only where it actually works |
| Previous Message | Masayuki Takahashi | 2018-08-19 04:28:34 | Re: How to estimate the shared memory size required for parallel scan? |