| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: windows cfbot failing: my_perl |
| Date: | 2022-08-27 07:11:13 |
| Message-ID: | 20220827071113.nl4q3frnizt4a6zw@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2022-08-26 23:02:06 -0400, Tom Lane wrote:
> John Naylor <john(dot)naylor(at)enterprisedb(dot)com> writes:
> > On Sat, Aug 27, 2022 at 4:15 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> I think it'd also be needed in hstore_plperl.c, jsonb_plperl.c. Putting the
> >> include in plperl.h would keep that aspect transparent, because plperl_utils.h
> >> includes plperl.h.
>
> > Since plperl_helpers.h already includes plperl.h, I'm not sure why
> > both are included everywhere the former is. If .c/.xs files didn't
> > include plperl.h directly, we could keep pg_wchar.h in
> > plperl_helpers.h. Not sure if that's workable or any better...
>
> Maybe we should flush the separate plperl_helpers.h header and just
> put those static-inline functions in plperl.h.
+1
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-08-27 07:23:44 | Re: windows cfbot failing: my_perl |
| Previous Message | John Naylor | 2022-08-27 06:59:06 | Re: use ARM intrinsics in pg_lfind32() where available |